BAB 4 PERANCANGAN SISTEM INFORMASI AKUNTANSI SIKLUS PENDAPATAN DAN PERSEDIAAN PADA PT. AFDHI SURYA MANDIRI

BAB 4 PERANCANGAN SISTEM INFORMASI AKUNTANSI SIKLUS PENDAPATAN DAN PERSEDIAAN PADA PT. AFDHI SURYA MANDIRI 4.1 Requirement Discipline 4.1.1 Prosedur Sistem yang Diusulkan Setelah memperoleh informasi mengenai proses bisnis yang berjalan pada perusahaan melalui wawancara dan observasi, kemudian mengidentifikasi masalahmasalah yang ada, maka perlu dibuat rekomendasi untuk mengatasi permasalahan tersebut dengan membandingkan teori yang ada dengan praktek di lapangan. Dimana, rekomendasi tersebut perlu untuk dimodelkan. Sistem yang dirancang dari rekomendasi tersebut akan digunakan untuk mendukung proses bisnis perusahaan dan membuat laporan yang dapat digunakan sebagai dasar dalam pengambilan keputusan oleh direksi di setiap periodenya. Proses bisnis yang diusulkan untuk siklus pendapatan dan persediaan adalah sebagai berikut. 1. Proses Pemesanan Unit Rumah Proses ini dimulai dengan kegiatan promosi unit rumah yang dilakukan oleh staff Promosi melalui spanduk, brosur, pemasangan iklan, mengikuti pameran, dan lain sebagainya. Untuk pelanggan yang tertarik terhadap unit rumah yang ditawarkan, maka dapat langsung mendatangi kantor pemasaran, yang kemudian akan dilayani oleh staff Marketing. Selain dapat memperoleh informasi mengenai unit rumah yang ditawarkan, pelanggan juga dapat meminta staff Marketing untuk melakukan representasi terhadap rumah contoh. Jika pelanggan memutuskan untuk melakukan pembelian terhadap unit rumah, maka pelanggan dapat menginformasikan unit rumah yang diinginkan kepada staff Marketing. Kemudian, staff Marketing akan melakukan pengecekan ketersediaan unit rumah dengan mengakses data Rumah. Jika status dari unit rumah tidak tersedia, maka staff Marketing akan menginformasikannya kepada pelanggan, dimana pelanggan dapat mengganti pesanan unit rumah atau tidak melanjutkan pemesanan. Sebaliknya, jika status unit rumah tersedia, maka staff Marketing akan meminta data pelanggan dan menginputnya ke dalam data Pelanggan. Proses ini tidak dapat berjalan apabila data yang diminta tidak lengkap. Setelah terdaftar, pelanggan diharuskan untuk membayar uang tanda jadi (Booking Fee) atas unit rumah yang dipesan. Pelanggan dapat melakukan pembayaran secara 79

80 tunai ataupun transfer. Jika pelanggan melakukan pembayaran melalui transfer, maka harus menyertakan Bukti Transfer (BT). Setelah menerima uang tanda jadi (Booking Fee) dari pelanggan, staff Marketing akan menginput data pelanggan dan data pemesanan unit rumah ke dalam Surat Pemesanan Rumah (SPR) dan mencetaknya sebanyak 3 rangkap. Setelah data SPR di input dan disimpan, maka sistem akan secara otomatis mengupdate status ketersediaan rumah menjadi Tidak Tersedia pada data Rumah, sehingga rumah yang telah dipesan tidak dapat dipesan oleh pelanggan yang lain. Kemudian, Bagian Marketing akan menginput pembayaran tanda jadi (Booking Fee) ke dalam Form Pembayaran Tanda Jadi. Selanjutnya, SPR yang sebelumnya telah dicetak akan diberikan kepada : a. Rangkap pertama akan disimpan oleh Bagian Marketing sebagai arsip. b. Rangkap ke-2 akan diberikan kepada pelanggan sebagai bukti bahwa pelanggan telah melakukan pemesanan unit rumah. c. Rangkap ke-3 beserta Bukti Transfer (BT) atau Bukti Setor (BS) akan diberikan ke Bagian Akuntansi untuk digunakan sebagai salah satu dasar dalam membuat Laporan Penerimaan Kas. Setelah itu, Bagian Marketing akan membuat Kuitansi untuk diserahkan ke pelanggan bersamaan dengan SPR sebagai bukti bahwa pelanggan telah melakukan pembayaran tanda jadi. Pada setiap akhir bulan, Bagian Marketing akan membuat Laporan Pemesanan Rumah berdasarkan pesanan yang tertera di dalam Form SPR yang telah tersimpan di dalam sistem. Laporan Pemesanan Rumah kemudian akan diserahkan ke Manajer Umum.

Gambar 4. 1 Activity Diagram Proses Pemesanan Unit Rumah yang Diusulkan 81

82 2. Proses Penjualan Tunai (Hard Cash) Proses penjualan tunai dimulai dengan pelanggan yang ingin melakukan pembayaran atas unit rumah yang telah dipesan, yaitu dengan memberikan SPR yang telah diterima sebelumnya ke Bagian Keuangan untuk di verifikasi. Bagian Keuangan akan menginput Nomor Form SPR yang diberikan oleh pelanggan ke dalam Form SPR dan kemudian mencocokkan antara Form SPR yang tersimpan dalam sistem dengan Form SPR yang diserahkan oleh pelanggan. Apabila data pada Form SPR valid, maka pelanggan dapat melakukan pembayaran atas unit rumah secara tunai ataupun transfer. Jika pelanggan melakukan pembayaran melalui transfer, maka harus menyertakan Bukti Transfer (BT) dan menyerahkannya ke Bagian Keuangan. Setelah menerima pembayaran dari pelanggan, Bagian Keuangan akan menginput pembayaran yang diterima ke dalam Form Pembayaran Rumah dan menyerahkan BT/BS yang diterima dari pelanggan ke Bagian Akuntansi. Kemudian, Bagian Keuangan akan membuat Kuitansi untuk diberikan kepada pelanggan sebagai bukti bahwa pelanggan telah melakukan pembayaran. Selanjutnya, Bagian Keuangan akan meminta pelanggan untuk memberikan datadata yang diperlukan untuk pengurusan surat-surat rumah. Dimana, data-data yang diperlukan antara lain : a. Fotokopi Kartu Tanda Penduduk (KTP) b. Fotokopi Surat Nikah atau fotokopi Surat Cerai jika duda/janda (optional) c. Pas foto 4x6 Apabila semua data-data telah lengkap, pelanggan akan menyerahkan data-data tersebut ke Bagian Perizinan. Kemudian, Bagian Perizinan akan mengurus Akta Jual Beli (AJB), sertifikat tanah, sertifikat balik nama atau unit rumah, dan suratsurat lainnya dengan notaris.

Gambar 4. 2 Activity Diagram Proses Penjualan Tunai yang Diusulkan 83

84 3. Proses Penjualan Kredit melalui KPR Bank Penjualan kredit melalui KPR Bank merupakan pembayaran unit rumah oleh pelanggan dengan melalui Bank sebagai perantaranya. Pelanggan harus terlebih dahulu mengajukan permohonan KPR kepada Bank yang bersangkutan. Dimana, selama proses pengajuan permohonan KPR, Bagian Perizinan akan membantu proses pengurusan permohonan KPR pelanggan dengan Bank. Sebelum dilakukannya pengajuan permohonan KPR, pelanggan harus melengkapi berkasberkas persyaratan pengajuan KPR. Berkas-berkas tersebut terdiri atas : a. Fotokopi Kartu Tanda Penduduk (KTP) b. Fotokopi Kartu Keluarga (KK) c. Fotokopi Surat Nikah atau fotokopi Surat Cerai jika duda/janda (optional) d. Pas foto 3x4 e. Fotokopi Nomor Pokok Wajib Pajak (NPWP) f. Surat Keterangan Kerja untuk karyawan swasta atau SK untuk PNS beserta fotokopinya g. Untuk karyawan swasta, Slip Gaji Asli 3 bulan beserta fotokopinya h. Untuk pengusaha, fotokopi SIUP TDP Keterangan Domisili atau Akta Pendirian Perusahaan, dan Laporan Keuangan 3 bulan terakhir i. Untuk profesional, fotokopi Surat Izin Praktek/Izin Profesi/SK Pengangkatan dari instansi terkait. Setelah semua persyaratan pengajuan permohonan KPR lengkap, maka Bagian Perizinan akan mengajukan permohonan KPR pelanggan ke Bank. Selanjutnya, pihak Bank akan melakukan wawancara dengan pelanggan. Jika permohonan KPR disetujui, maka sesuai dengan peraturan Bank, pelanggan diharuskan untuk melakukan pembayaran uang muka (DP) sebesar 20% dari harga jual ke perusahaan. Bagian Keuangan terlebih dahulu akan memverifikasi pesanan pelanggan, yaitu dengan menginput Nomor Form SPR yang diberikan oleh pelanggan ke dalam Form SPR dan kemudian mencocokkan antara Form SPR yang tersimpan dalam sistem dengan Form SPR yang diserahkan oleh pelanggan. Apabila data pada Form SPR valid, maka pelanggan dapat menyerahkan pembayaran DP dan Bukti Transfer (BT), jika pembayaran dilakukan melalui transfer, ke Bagian Keuangan. Namun jika pelanggan melakukan pembayaran DP secara tunai, maka Bagian Keuangan akan menyetorkan pembayaran yang

85 diterima ke Bank dan menerima Bukti Setor (BS). Setelah itu, pembayaran DP dari pelanggan akan di input oleh Bagian Keuangan ke dalam Form KPR dan mencetaknya sebanyak 2 rangkap untuk diberikan kepada : a. Rangkap pertama akan diberikan ke Bank sebagai bukti bahwa pelanggan telah melakukan pembayaran DP ke perusahaan. b. Rangkap ke-2 dan BT atau BS akan diberikan ke Bagian Akuntansi sebagai salah satu dasar dalam membuat Laporan Penerimaan Kas. Pencatatan pembayaran DP tersebut hanya bersifat informatif dan tidak diakui sebagai pendapatan bagi perusahaan karena perusahaan hanya bertindak sebagai pihak perantara antara pelanggan dengan Bank, dimana DP yang telah dibayarkan oleh pelanggan tersebut akan diserahkan oleh perusahaan ke Bank. Kemudian, Bagian Keuangan akan membuat Kuitansi untuk diberikan ke pelanggan sebagai bukti bahwa pelanggan telah melakukan pembayaran DP ke perusahaan. Selanjutnya, berdasarkan Form KPR yang diberikan oleh perusahaan, Bank akan menerbitkan Surat Penegasan Persetujuan Pemberian Kredit (SP3K) yang memuat semua informasi mengenai kredit yang diberikan, seperti jumlah uang muka (DP) yang dibayarkan kepada perusahaan, suku bunga, dan jangka waktu kredit. Salinan SP3K akan diberikan oleh Bank kepada : a. Pelanggan, sebagai bukti bahwa KPR telah disetujui oleh di Bank dan didalamnya memuat biaya-biaya yang harus dibayarkan oleh pelanggan. b. Bagian Keuangan, sebagai bukti bahwa permohonan KPR telah disetujui oleh Bank dan kemudian akan disimpan sebagai arsip. Setelah diterbitkannya SP3K, maka akad kredit yang melibatkan pelanggan, Bank, pihak perusahaan yaitu dalam hal ini Bagian Perizinan, dan Notaris dapat dilaksanakan. Akad kredit merupakan pelaksanaan penandatanganan Perjanjian Kredit, Akta Jual Beli (AJB), Surat Kuasa Membebankan Hak Tanggungan (SKMHT) atau Akta Pembebanan Hak Tanggungan (APHT), dan surat-surat lainnya yang diperlukan. Data-data yang diperlukan untuk pengurusan surat-surat tersebut akan diberikan oleh Bagian Perizinan ke pihak Bank. Surat-surat yang dihasilkan dari akad kredit akan ditahan oleh pihak Bank sebagai jaminan kredit pelanggan dan akan diberikan ke pelanggan apabila angsuran KPR sudah lunas.

86 Setiap bulannya, pelanggan akan melakukan pembayaran cicilan KPR ke Bank. Kemudian, Bank akan memberikan bukti pembayaran cicilan KPR pelanggan ke perusahaan. Bagian Keuangan akan menginput pembayaran cicilan KPR pelanggan yang diterima setiap bulannya ke dalam Pembayaran Cicilan KPR untuk memantau perkembangan pembayaran KPR pelanggan. Namun, jika pengajuan permohonan KPR dari pelanggan ditolak oleh Bank, maka Bagian Perizinan selaku pihak yang mengurus permohonan KPR pelanggan akan menginformasikan kepada pelanggan bahwa permohonan KPR ditolak. Pelanggan kemudian akan diberikan dua alternatif, yaitu tetap melakukan pembelian unit rumah dengan mengganti metode pembayaran atau tidak melanjutkan pembelian. Jika pelanggan ingin tetap melanjutkan pembelian atas unit rumah, maka pelanggan dapat mengganti metode pembayaran, yaitu melakukan pembayaran secara tunai atau kredit in house.

Gambar 4. 3 Activity Diagram Proses Penjualan Kredit melalui KPR Bank yang Diusulkan 87

88 4. Proses Penjualan Kredit In House Penjualan kredit in house merupakan penjualan unit rumah secara kredit langsung kepada PT. Afdhi Surya Mandiri. Perusahaan menetapkan kebijakan bahwa pembayaran akan dibagi ke dalam empat tahap dalam jangka waktu 1 tahun dimana setiap cicilan akan ditagihkan setiap tiga bulan sekali, yaitu pembayaran pertama sebesar 40% dari harga jual, pembayaran ke-2 sebesar 20%, pembayaran ke-3 sebesar 20%, dan pembayaran ke-4 sebesar 20%. Jika pelanggan setuju dengan kebijakan kredit tersebut, maka pelanggan dapat mengajukan permohonan kredit in house dengan melampirkan SPR ke Manajer Umum. Kemudian, Manajer Umum akan melakukan penilaian terhadap pelanggan untuk menentukan apakah pelanggan layak untuk diberikan fasilitas kredit atau tidak dengan melakukan analisa 5C (Character, Capacity, Capital, Collateral, dan Conditions). Penilaian tersebut dilakuan dengan cara mengadakan wawancara langsung dengan pelanggan. Manajer akan memberikan nilai pada masing-masing kriteria berdasarkan pengamatannya dan kemudian akan menghitung total nilai tersebut. Kriteria dan penilaian akan digambarkan pada tabel 4.1. Tabel 4. 1 Kriteria dan Penilaian 5C Kriteria Keterangan Nilai Character Apakah data yang pelanggan berikan dapat dipercaya kelengkapan dan kebenerannya? Daftar Pertanyaan: 1. Apakah Pelanggan pernah menjalankan usaha lain sebelumnya? 2. Apakah Pelangan telah menjalani usaha selama lebih dari 5 tahun? 3. Apakah Pelanggan tidak pernah memiliki catatan kriminal di kepolisian? 4. Apakah Pelanggan selalu melunasi piutangnya pada bank atau lembaga lainnya tepat waktu? Penilaian:

89 Capacity Capital Semua jawaban sesuai kriteria 3 Jawaban sesuai kriteria 2 Jawaban sesuai kriteria 1 Jawaban sesuai kriteria Tidak ada jawaban sesuai kriteria Apakah hasil usaha yang diperoleh pelanggan mampu untuk melunasi kewajibannya tepat waktu? Daftar pertanyaan: 1. Apakah penjualan Pelanggan dalam bentuk tunai lebih banyak dari kredit? 2. Apakah Pelanggan umumnya memiliki order setiap hari? 3. Apakah Pelanggan memiliki usaha lain? 4. Apakah pelanggan selalu mengontroldan mengelola usahanya secara disiplin setiap hari? Penilaian: Semua jawaban sesuai kriteria 3 Jawaban sesuai kriteria 2 Jawaban sesuai kriteria 1 Jawaban sesuai kriteria Tidak ada jawaban sesuai kriteria Apakah kondisi kekayaan yang dimiliki oleh pelanggan layak dan sesuai dengan jumlah kredit yang disepakati? Daftar pertanyaan: 1. Apakah tempat usaha yang dimiliki pelanggan merupakan milik sendiri? 2. Apakah pelanggan memiliki tingkat utang yang melebihi modal? 3. Apakah aset yang dimiliki oleh pelanggan berasal dari akumulasi keuntungan pelanggan ataukah modal sendiri? 4. Apakah pelanggan memiliki lebih dari satu 5 4 3 2 1 5 4 3 2 1

90 Collateral Condition tempat usaha? Penilaian: Semua jawaban sesuai kriteria 3 Jawaban sesuai kriteria 2 Jawaban sesuai kriteria 1 Jawaban sesuai kriteria Tidak ada jawaban sesuai kriteria Apakah jaminan yang diberikan oleh pelanggan bisa memenuhi kewajibannya? Daftar pertanyaan: 1. Apakah pelanggan memiliki harta yang bisa dijadikan sebagai jaminan? 2. Apakah jaminan yang diberikan oleh pelanggan merupakan jaminan dengan nilai ekonomis yang tinggi? 3. Apakah harta dari pelanggan memiliki likuiditas yang baik? 4. Apakah pelanggan memilki harta yang lain bisa dijadikan subtitusi? Penilaian: Semua jawaban sesuai kriteria 3 Jawaban sesuai kriteria 2 Jawaban sesuai kriteria 1 Jawaban sesuai kriteria Tidak ada jawaban sesuai kriteria Apakah usaha pelanggan termasuk yang berkembang diantara kompetitor wilayahnya? Sangat Berkembang Cukup Berkembang Biasa Saja Tidak Berkembang Sangat Tidak Berkembang 5 4 3 2 1 5 4 3 2 1 5 4 3 2 1

91 Hasil penilaian terhadap kriteria 5C : Hasil penilaian dari setiap kriteria akan di total jumlahnya dan kemudian akan diperoleh hasil sebagai berikut : Jika total nilai 1 10 : Pelanggan belum layak untuk mendapatkan fasilitas kredit in house dari perusahaan. Jika total nilai 11 25 : Pelanggan dianggap layak untuk mendapatkan fasilitas kredit in house dari perusahaan. Manajer Umum akan memberikan hasil analisa 5C pelanggan kepada Direktur Utama. Jika dari hasil penilaian tersebut pelanggan layak untuk mendapatkan fasilitas kredit in house, maka Direktur Utama memberikan persetujuan untuk memberikan kredit kepada pelanggan, kemudian Manajer Umum akan memberikan stempel Credit Approved pada SPR Pelanggan. Selanjutnya, pelanggan dapat memproses pembayaran ke Bagian Keuangan. Bagian Keuangan akan terlebih dahulu memverifikasi pesanan pelanggan dengan menginput Nomor Form SPR yang diberikan oleh pelanggan ke dalam Form SPR dan kemudian mencocokkan antara Form SPR yang tersimpan dalam sistem dengan Form SPR pelanggan. Apabila data Form SPR valid, maka Bagian Keuangan akan membuat Surat Perjanjian Jual Beli (SPJB) sebanyak 2 rangkap, sebagai bukti bahwa pelanggan telah menyetujui kesepakatan kredit in house dengan perusahaan. SPJB tersebut akan diserahkan ke pelanggan untuk ditandatangani. Setelah SPJB tersebut ditandatangani, maka: a. SPJB rangkap pertama akan disimpan oleh pelanggan sebagai bukti persetujuan terhadap kesepakatan kredit in house atas unit rumah dan juga tercantum jumlah pembayaran cicilan dan tanggal jatuh temponya. b. SPJB rangkap ke-2 yang telah ditandatangani oleh pelanggan akan dikembalikan ke Bagian Keuangan, yang kemudian akan menyimpannya sebagai arsip. Setelah menerima SPJB yang telah ditandatangani oleh pelanggan, maka Bagian Keuangan akan menginput pembayaran cicilan rumah ke dalam Form Pembayaran Cicilan Rumah. Dimana, Bagian Keuangan akan menginput tanggal Jatuh Tempo dan Nominal Cicilan untuk pembayaran pertama, kemudian sistem

92 akan secara otomatis men-generate tanggal jatuh tempo dan nominal cicilan untuk pembayaran cicilan ke-2, ke-3, dan ke-4. Pada saat dilakukannya penagihan cicilan pertama, Bagian Keuangan akan membuat Faktur Penagihan sebagai dasar untuk melakukan penagihan pembayaran cicilan pertama dari pelanggan dan mencetaknya sebanyak 4 rangkap. Bagian Keuangan akan menyerahkan Faktur Penagihan tersebut ke Bagian Penagihan untuk melakukan penagihan kepada pelanggan. Pelanggan dapat melakukan pembayaran pertama secara tunai ataupun transfer. Jika pelanggan melakukan pembayaran melalui transfer, maka harus menyertakan Bukti Transfer (BT) dan menyerahkannya kepada Bagian Penagihan. Pelanggan akan melakukan pembayaran pertama dan kemudian : a. Faktur Penagihan rangkap pertama akan disimpan oleh pelanggan. Bagian Penagihan akan menerima Faktur Penagihan rangkap 2, 3, 4 yang telah ditandatangani oleh pelanggan beserta BT (jika ada). b. Faktur Penagihan rangkap ke-2 akan disimpan oleh Bagian Penagihan sebagai bukti bahwa telah dilakukannya penagihan ke pelanggan. c. Jika pembayaran dilakukan melalui transfer, maka Faktur Penagihan rangkap ke-3 dan Bukti Transfer (BT) akan diberikan ke Bagian Keuangan. Sedangkan, jika pembayaran secara tunai, maka Bagian Keuangan akan menyetorkan pembayaran yang diterima ke Bank dan menerima Bukti Setor (BS). Bagian Keuangan akan mengarsip Faktur Penagihan rangkap ke-3, dan kemudian menyerahkan BT atau BS ke Bagian Akuntansi. d. Setelah pembayaran di input ke dalam sistem, Faktur Penagihan rangkap ke-4 dan BT atau BS akan diberikan ke Bagian Akuntansi sebagai salah satu bukti dalam membuat Laporan Penerimaan Kas. Setelah menerima kembali Faktur Penagihan beserta pelunasan cicilan pertama dari pelanggan, Bagian Keuangan mengupdate detail pembayaran pertama pada Pembayaran Cicilan Rumah yang telah dibuat sebelumnya. Bagian Keuangan akan mencentang status pembayaran 1 menjadi Lunas dan menginput detail pembayaran 1. Kemudian, Bagian Keuangan akan membuat Kuitansi untuk diberikan ke pelanggan sebagai bukti bahwa pelanggan telah melakukan pembayaran pertama. Selanjutnya, Bagian Keuangan akan meminta pelanggan

93 untuk memberikan data-data yang diperlukan untuk pengurusan surat-surat rumah. Dimana, data-data yang diperlukan antara lain : a. Fotokopi Kartu Tanda Penduduk (KTP) b. Fotokopi Surat Nikah atau fotokopi Surat Cerai jika duda/janda (optional) c. Pas foto 4x6 Apabila semua data-data telah lengkap, pelanggan akan menyerahkan data-data tersebut ke Bagian Perizinan. Kemudian, Bagian Perizinan akan mengurus Akta Jual Beli (AJB), sertifikat tanah, sertifikat balik nama atau unit rumah, dan suratsurat lainnya dengan notaris. Surat-surat tersebut akan disimpan oleh Bagian Keuangan dan akan diberikan ke pelanggan jika semua pembayaran cicilan unit rumah sudah lunas.

94 Gambar 4. 4 Activity Diagram Proses Penjualan Kredit In House yang Diusulkan

95 5. Proses Penagihan Piutang Untuk penjualan melalui kredit in house, pembayaran dilakukan oleh pelanggan melalui cicilan sebanyak empat kali kepada perusahaan. Pembayaran Cicilan Rumah yang telah di input sebelumnya ke dalam sistem oleh Bagian Keuangan akan berisi tanggal jatuh tempo dari setiap pembayaran cicilan, sehingga 14 hari (dua minggu) sebelum tanggal jatuh tempo dari setiap pembayaran, sistem akan memberikan notifikasi kepada Bagian Keuangan bahwa piutang pelanggan akan mendekati tanggal jatuh tempo. Setelah menerima notifikasi dari sistem, Bagian Keuangan akan menghubungi pelanggan via telepon untuk memberitahu bahwa piutang pelanggan akan jatuh tempo dua minggu lagi dan pelanggan di mohon untuk melakukan pembayaran kepada Bagian Penagihan pada saat tanggal jatuh tempo. Bagian Keuangan kemudian akan mencetak Faktur Penagihan berdasarkan notifikasi sistem mengenai Pembayaran Cicilan yang mendekati jatuh tempo sebanyak 4 rangkap, yang kemudian akan diserahkan kepada Bagian Penagihan untuk melakukan penagihan ke pelanggan pada saat tanggal jatuh tempo. Pelanggan dapat melakukan pembayaran secara tunai atau transfer. Jika pembayaran dilakukan melalui transfer, maka pelanggan harus menyertakan Bukti Transfer (BT) dan menyerahkannya ke Bagian Penagihan. Pelanggan akan melakukan pembayaran dan kemudian : a. Faktur Penagihan rangkap pertama akan diberikan kepada pelanggan sebagai bukti pembayaran angsuran atau cicilan. b. Faktur Penagihan rangkap ke-2 akan disimpan oleh Bagian Penagihan sebagai bukti bahwa penagihan telah dilakukan. c. Jika pembayaran dilakukan melalui transfer, maka Faktur Penagihan rangkap ke-3 beserta BT akan diberikan ke Bagian Keuangan. Sedangkan, jika pembayaran secara tunai, maka Bagian Keuangan akan menyetorkan pembayaran yang diterima ke Bank dan menerima Bukti Setor (BS). Bagian Keuangan akan mengarsip Faktur Penagihan rangkap ke-3 dan menyerahkan BT atau BS ke Bagian Akuntansi. d. Setelah pembayaran cicilan rumah di input ke dalam sistem, Faktur Penagihan rangkap ke-4 dan BT atau BS akan diberikan kepada Bagian Akuntansi sebagai salah satu dasar dalam membuat Laporan Penerimaan Kas.

96 Setiap dilakukannya pembayaran cicilan oleh pelanggan, Bagian Keuangan akan mengupdate data Pembayaran Cicilan Rumah yang telah dibuat sebelumnya, yaitu mengupdate status pembayaran cicilan menjadi Lunas dan menginput detail pembayaran tersebut. Kemudian, Bagian Keuangan akan membuat Kuitansi untuk diberikan ke pelanggan sebagai bukti bahwa pelanggan telah melakukan pembayaran cicilan unit rumah. Apabila semua pembayaran cicilan sudah lunas, maka Bagian Keuangan akan mengubah status Pembayaran Cicilan Rumah menjadi Closed.

Gambar 4. 5 Activity Diagram Proses Penagihan Piutang yang Diusulkan 97

98 6. Proses Pencatatan Penerimaan Kas Proses ini dimulai dengan penyerahan SPR oleh Bagian Marketing serta penyerahan data KPR, Faktur Penagihan beserta Bukti Transfer (BT) atau Bukti Setor (BS) oleh Bagian Keuangan ke Bagian Akuntansi. Kemudian, Bagian Akuntansi akan melakukan pengecekan terhadap semua pembayaran (Pembayaran Tanda Jadi, Pembayaran Rumah, Pembayaran DP untuk KPR, dan Pembayaran Cicilan Rumah) yang tersimpan pada sistem dengan mencocokkan pada sistem, pembayaran yang telah di input dengan SPR, data KPR, dan Faktur Penagihan yang telah ditagihkan, sehingga akan memberikan keabsahan bahwa pembayaran memang berasal dari SPR, data KPR, dan Faktur Penagihan yang telah dikeluarkan. Kemudian, pada akhir periode, Bagian Akuntansi akan membuat Laporan Piutang, Laporan Penerimaan Kas, dan Laporan Jurnal, yang pada akhirnya akan diberikan kepada Manajer Umum. Gambar 4. 6 Activity Diagram Proses Pencatatan Penerimaan Kas yang Diusulkan

99 7. Proses Pengelolaan Unit Rumah Terkait dengan siklus pendapatan, PT. Afdhi Surya Mandiri mengelola persediaan berupa unit rumah untuk dijual ke pelanggan. Proses ini dimulai pembuatan rancangan dan desain pembangunan oleh Arsitek sesuai dengan konsep yang diusulkan. Jika rancangan dan desain yang dibuat oleh Arsitek disetujui oleh Direktur Utama, maka akan diadakannya rapat internal untuk membahas mengenai rencana kerja proyek pembangunan. Berdasarkan hasil dari rapat tersebut, dihasilkan data Rumah dan Spesifikasi Teknis mengenai unit rumah yang akan dibangun. Arsitek akan menginput data Rumah bersamaan dengan Spesifikasi Teknis ke dalam sistem. Setelah itu, Manajer Umum akan membuat dan mencetak Surat Perintah Mulai Bangun (SPMB). SPMB tersebut akan ditandatangani oleh Direktur Utama dan setelah itu diberikan ke Bagian Keuangan. Setelah menerima SPMB yang telah ditandatangani, maka Bagian Keuangan akan membuat Surat Perintah Kerja (SPK), yang berisi spesifikasi teknis mengenai unit rumah, volume, dan harga atau nilai borongan. SPK akan dicetak sebanyak tiga rangkap dan diserahkan kepada Manajer Umum untuk ditandatangani. Setelah diotorisasi oleh Manajer Umum, maka SPK akan diberikan untuk : a. SPK rangkap pertama akan diarsip oleh Bagian Keuangan. b. SPK rangkap 2 dan 3 akan diberikan ke Bagian Pengawas Lapangan dan Bagian Pelaksana sebagai dasar untuk mulai melakukan proyek pembangunan. Setelah menerima SPK dari Bagian Keuangan, maka Bagian Pengawas Lapangan akan mengarsip SPK rangkap ke-2 dan membentuk tim pelaksana untuk melakukan pekerjaan proyek pembangunan. Setelah tim pelaksana terbentuk, maka Bagian Pengawas Lapangan akan menyerahkan SPK rangkap ke-3 ke Bagian Pelaksana. Berdasarkan SPK tersebut, Bagian Pelaksana akan mulai untuk melakukan pekerjaan proyek pembangunan. Selama proses pengerjaan, Bagian Pengawas Lapangan akan melakukan pengawasan fisik terhadap perkembangan dari proyek pembangunan di lapangan dan di input ke dalam Progress Kerja Mingguan, yang kemudian akan dilaporkan kepada Manajer Umum. Jika pembangunan telah selesai, maka data-data mengenai unit rumah

100 yang telah dibangun akan dicatat oleh Bagian Pelaksana ke dalam Berita Acara Serah Terima (BAST), yang memuat keterangan bahwa unit rumah telah selesai dibangun dan telah dilakukan pengecekan sesuai dengan yang tertera di dalam SPK. BAST tersebut akan diberikan ke Bagian Pengawas Lapangan untuk dicocokkan dengan SPK. Apabila data-data yang tertera dalam BAST sudah valid, maka Bagian Pengawas Lapangan akan mengupdate status pembangunan rumah menjadi Selesai Dibangun dengan mengakses Data Rumah dan menyerahkan BAST ke Bagian Keuangan untuk diarsip. Setelah itu, Bagian Pengawas Lapangan akan membuat Laporan Hasil Kerja sebagai rekapitulasi dari Progress Kerja Mingguan yang telah dibuat sebelumnya.

Gambar 4. 7 Activity Diagram Proses Pengelolaan Unit Rumah yang Diusulkan 101

102 4.2 Use Case and Domain Classes 4.2.1 Event Table Tabel 4. 2 Event Table No Event Trigger Source Use Case Response Destination 1 Arsitek menginput data rumah yang akan dibangun Adanya rancangan dan desain pembangunan yang telah disetujui oleh Direktur Utama Arsitek Menginput Data Rumah Data Rumah - 2 3 Manajer Umum membuat Surat Perintah Mulai Bangun (SPMB) Bagian Keuangan membuat Surat Perintah Kerja (SPK) Adanya rencana kerja yang harus direalisasikan Adanya SPMB yang diterima Arsitek Manajer Umum Membuat Surat Perintah Mulai Bangun Membuat Surat Perintah Kerja Surat Perintah Mulai Bangun Surat Perintah Kerja Bagian Keuangan Bagian Pengawas Lapangan dan Bagian Pelaksana 4 Bagian Pelaksana membuat Berita Acara Serah Terima Unit rumah telah selesai dibangun Bagian Pelaksana Membuat Berita Acara Serah Terima Berita Acara Serah Terima Bagian Pengawas Lapangan 5 Bagian Pengawas Lapangan mengupdate status pembangunan rumah menjadi Selesai Dibangun Adanya BAST yang diterima dan telah di cek Bagian Pelaksana Mengupdate Data Rumah Data Rumah -

103 6 Bagian Marketing mengecek ketersediaan unit rumah yang diinginkan oleh pelanggan Adanya pemesanan terhadap unit rumah Pelanggan Mengecek Ketersediaan Rumah Data Rumah Pelanggan 7 Bagian Marketing mencatat data pelanggan Unit rumah yang dipesan oleh pelanggan tersedia Pelanggan Menginput Data Pelanggan Data Pelanggan - 8 Setelah menerima pembayaran uang tanda jadi (Booking Fee), Bagian Marketing membuat Surat Pemesanan Rumah (SPR) Adanya pemesanan terhadap unit rumah dan pembayaran uang tanda jadi (Booking Fee) Pelanggan Membuat Surat Pemesanan Rumah Surat Pemesanan Rumah Pelanggan, Bagian Akuntansi 9 Bagian Marketing menginput pembayaran tanda jadi Adanya pembayaran tanda jadi (Booking Fee) yang diterima dari pelanggan Pelanggan Menginput Pembayaran Tanda Jadi Pembayaran Tanda Jadi - 10 Bagian Keuangan memverifikasi SPR pelanggan dengan menginput Nomor SPR Adanya pembayaran atas unit rumah yang dilakukan oleh pelanggan Pelanggan Mengecek Surat Pemesanan Rumah Data Surat Pemesanan Rumah Bagian Keuangan 11 Untuk pelanggan yang melakukan pembayaran secara tunai, Bagian Keuangan menginput pembayaran rumah ke dalam Pembayaran Rumah Adanya pembayaran unit rumah secara tunai yang diterima dari pelanggan dan SPR pelanggan valid Pelanggan Menginput Pembayaran Rumah Pembayaran Rumah -

104 12 Untuk pelanggan yang melakukan pembayan melalui KPR Bank, Bagian Keuangan akan menginput pembayaran DP pelanggan ke dalam data KPR Adanya pembayaran DP yang diterima dari pelanggan untuk penjualan melalui KPR Bank dan SPR pelanggan valid Pelanggan Menginput Data KPR Data KPR Bagian Akuntansi, Bank 13 Setiap bulannya, Bank akan memberikan bukti pembayaran cicilan KPR pelanggan ke perusahaan. Kemudian, Bagian Keuangan akan menginput pembayaran cicilan KPR pelanggan tersebut ke dalam Pembayaran Cicilan KPR Adanya bukti pembayaran cicilan KPR yang diterima Bank Menginput Pembayaran Cicilan KPR Pembayaran Cicilan KPR - 14 Untuk pelanggan yang melakukan pembayaran secara kredit in house dan permohonan kreditnya telah disetujui oleh Manajer Umum, maka Bagian Keuangan akan membuat Surat Perjanjian Jual Beli (SPJB) Adanya penjualan unit rumah secara kredit in house yang telah disetujui dan SPR pelanggan valid Pelanggan Membuat Surat Perjanjian Jual Beli Surat Perjanjian Jual Beli Pelanggan 15 16 Bagian Keuangan menginput Pembayaran Cicilan Rumah Bagian Keuangan membuat Faktur Penagihan untuk menagih pembayaran cicilan unit rumah Adanya Surat Perjanjian Jual Beli yang telah ditandatangani Piutang pelanggan akan jatuh tempo Pelanggan Bagian Keuangan Menginput Pembayaran Cicilan Rumah Membuat Faktur Penagihan Pembayaran Cicilan Rumah Faktur Penagihan - Pelanggan

105 17 Bagian Penagihan akan melakukan penagihan ke pelanggan berdasarkan Faktur Penagihan dan kemudian menyerahkan Bukti Transfer atau Uang yang diterima ke Bagian Keuangan. Selanjutnya, Bagian Keuangan akan mengupdate Pembayaran Cicilan Rumah Menerima kembali Faktur Penagihan yang telah ditandatangani bersamaan dengan pembayaran cicilan rumah Pelanggan Mengupdate Pembayaran Cicilan Rumah Data Pembayaran Cicilan Rumah - 18 Bagian Pengawas Lapangan membuat Progress Kerja Mingguan Akhir Minggu Bagian Pelaksana Membuat Progress Kerja Mingguan Progress Kerja Mingguan Manajer Umum 19 Bagian Pengawas Lapangan membuat Laporan Hasil Kerja Pembangunan telah selesai Bagian Pengawas Lapangan Generate Laporan Hasil Kerja Laporan Hasil Kerja Manajer Umum 20 21 22 23 Bagian Marketing membuat Laporan Pemesanan Rumah Bagian Akuntansi membuat Laporan Piutang Bagian Akuntansi membuat Laporan Penerimaan Kas Bagian Akuntansi membuat Laporan Jurnal Akhir Bulan Akhir Bulan Akhir Bulan Akhir Bulan Bagian Marketing Bagian Keuangan Bagian Akuntansi Bagian Akuntansi Generate Laporan Pemesanan Rumah Generate Laporan Piutang Generate Laporan Penerimaan Kas Generate Laporan Jurnal Laporan Pemesanan Rumah Laporan Piutang Laporan Penerimaan Kas Laporan Jurnal Manajer Umum Manajer Umum Manajer Umum Manajer Umum

106 4.2.1 Use Case Diagram Gambar 4. 8 Use Case Diagram Prosedur Sistem yang Diusulkan

107 4.2.3 Use Case Description Tabel 4. 3 Use Case Description Menginput Data Rumah Use Case Name : Menginput Data Rumah Scenarios : Arsitek menginput Data Rumah berdasarkan rancangan dan desain pembangunan Triggering Event : Adanya rancangan dan desain pembangunan yang telah disetujui oleh Direktur Utama Brief Description : Arsitek melakukan login, memilih menu Rumah, menambah data rumah baru, menginput data rumah tersebut, dan menyimpannya Actors : Arsitek Related Use Cases : - Stakeholders : Manajer Umum : sebagai dasar untuk membuat Surat Perintah Mulai Bangun Preconditions : Arsitek melakukan login, rancangan dan desain pembangunan telah disetujui Postconditions : Data Rumah terbentuk Flow of Events : Actor System 1. Arsitek melakukan login 1.1 Memvalidasi username 1.2 Memvalidasi password 2. Arsitek memilih menu 2.1 Membuka Form Exception Conditions : Rumah 3. Arsitek menambah data rumah 4. Arsitek menginput data rumah 5. Arsitek menambah data spesifikasi teknis 6. Arsitek menginput data spesifikasi teknis 7. Arsitek menyimpan data rumah - Master Rumah 3.1 Menampilkan No_Rumah 4.1 Memvalidasi Tipe 4.2 Memvalidasi Harga_Jual 5.1 Menampilkan No_Spesifikasi - 7.1 Data Rumah tersimpan

108 Tabel 4. 4 Use Case Description Membuat Surat Perintah Mulai Bangun Use Case Name : Scenarios : Triggering Event : Brief Description : Membuat Surat Perintah Mulai Bangun Manajer Umum membuat Surat Perintah Mulai Bangun sebagai hasil dari rapat internal mengenai rencana kerja Adanya rencana kerja yang harus direalisasikan Manajer Umum melakukan login, memilih menu Surat Perintah Mulai Bangun, menambah data Surat Perintah Mulai Bangun baru, menginput data Surat Perintah Mulai Bangun, dan kemudian menyimpan dan mencetaknya Manajer Umum Actors : Related Use Cases : - Stakeholders : - Direktur Utama : memberikan persetujuan dan otorisasi untuk memulai pembangunan - Bagian Keuangan : sebagai dasar untuk membuat Surat Perintah Kerja Preconditions : Manajer Umum melakukan login dan harus ada rencana kerja yang telah disepakati Postconditions : Surat Perintah Mulai Bangun terbentuk Flow of Events : Actor System 1. Manajer Umum melakukan login 1.1 Memvalidasi username 1.2 Memvalidasi password 2. Manajer Umum memilih menu Surat Perintah Mulai Bangun 3. Manajer Umum menambah data Surat Perintah Mulai Bangun 4. Manajer Umum menginput data Surat Perintah Mulai Bangun 5. Manajer Umum memilih Nomor Rumah 6. Manajer Umum menambahkan data rumah yang telah dipilih 7. Mengulangi langkah 5 dan 6 sampai data rumah selesai 2.1 Membuka Form Surat Perintah Mulai Bangun 3.1 Menampilkan No_SPMB 5.1 Menampilkan No_Spesifikasi 5.2 Menampilkan Tipe 6.1 Menambahkan data Rumah - -

109 Exception Conditions : ditambahkan 8. Manajer Umum menyimpan Surat Perintah Mulai Bangun 9. Manajer Umum mencetak Surat Perintah Mulai Bangun - 8.1 Surat Perintah Mulai Bangun tersimpan 9.1 Surat Perintah Mulai Bangun tercetak Tabel 4. 5 Use Case Description Membuat Surat Perintah Kerja Use Case Name : Scenarios : Triggering Event : Brief Description : Membuat Surat Perintah Kerja Bagian Keuangan membuat Surat Perintah Kerja setelah menerima Surat Perintah Mulai Bangun Adanya Surat Perintah Mulai Bangun yang diterima Bagian Keuangan melakukan login, memilih menu Surat Perintah Kerja, menambah data Surat Perintah Kerja baru, menginput data Surat Perintah Kerja, dan kemudian menyimpan dan mencetaknya Bagian Keuangan Actors : Related Use Cases : - Stakeholders : - Manajer Umum : memberikan persetujuan dan otorisasi untuk memulai pembangunan - Bagian Pengawas Lapangan : sebagai dasar untuk membentuk tim pelaksana dan melakukan pengawasan terhadap pelaksanaan pekerjaan pembangunan - Bagian Pelaksana : sebagai dasar untuk melaksanakan pekerjaan pembangunan Preconditions : Bagian Keuangan melakukan login, harus ada Surat Perintah Mulai Bangun yang ditandatangani oleh Direktur Utama Postconditions : Surat Perintah Kerja terbentuk Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Keuangan melakukan login username 1.2 Memvalidasi password 2. Bagian Keuangan memilih menu Surat Perintah Kerja 3. Bagian Keuangan menambah data Surat Perintah Kerja 4. Bagian Keuangan memilih Nomor Surat 2.1 Membuka Form Surat Perintah Kerja 3.1 Menampilkan No_SPK 4.1 Menampilkan data Surat Perintah Mulai

110 Exception Conditions : Perintah Mulai Bangun 5. Bagian Keuangan menginput data Surat Perintah Kerja 6. Bagian Keuangan menyimpan Surat Perintah Kerja 7. Bagian Keuangan mencetak Surat Perintah Kerja - Bangun 5.1 Memvalidasi Harga_Borongan 6.1 Surat Perintah Kerja tersimpan 7.1 Surat Perintah Kerja tercetak Tabel 4. 6 Use Case Description Membuat Berita Acara Serah Terima Use Case Name : Scenarios : Triggering Event : Brief Description : Membuat Berita Acara Serah Terima Bagian Pelaksana membuat Berita Acara Serah Terima setelah unit rumah selesai dibangun Unit rumah telah selesai dibangun Bagian Pelaksana melakukan login, memilih menu Berita Acara Serah Terima, menambah data Berita Acara Serah Terima baru, menginput data Berita Acara Serah Terima, dan kemudian menyimpan dan mencetaknya Bagian Pelaksana Actors : Related Use Cases : - Stakeholders : - Bagian Pengawas Lapangan : untuk mengecek apakah sudah sesuai dengan yang tertera Surat Perintah Kerja - Bagian Keuangan : untuk disimpan sebagai arsip Preconditions : Bagian Pelaksana melakukan login, unit rumah sudah selesai dibangun Postconditions : Berita Acara Serah Terima terbentuk Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Pelaksana melakukan login username 1.2 Memvalidasi password 2. Bagian Pelaksana memilih menu Berita Acara Serah Terima 3. Bagian Pelaksana menambah data Berita Acara Serah Terima 4. Bagian Pelaksana memilih Nomor Surat Perintah Kerja 2.1 Membuka Form Berita Acara Serah Terima 3.1 Menampilkan No_BAST 4.1 Menampilkan Tanggal_SPK 4.2 Menampilkan data

111 Exception Conditions : 5. Bagian Pelaksana menginput data Berita Acara Serah Terima 6. Bagian Pelaksana menyimpan Berita Acara Serah Terima 7. Bagian Pelaksana mencetak Berita Acara Serah Terima - Surat Perintah Mulai Bangun 6.1 Berita Acara Serah Terima tersimpan 7.1 Berita Acara Serah Terima tercetak - Use Case Name : Tabel 4. 7 Use Case Description Mengupdate Data Rumah Mengupdate Data Rumah Scenarios : Bagian Pengawas Lapangan mengupdate data rumah berdasarkan Berita Acara Serah Terima Triggering Event : Adanya Berita Acara Serah Terima yang diterima dan telah di cek Brief Description : Bagian Pengawas Lapangan melakukan login, memilih menu Rumah, memilih Nomor Rumah, mengupdate status pembangunan rumah, dan kemudian menyimpannya Actors : Bagian Pengawas Lapangan Related Use Cases : - Stakeholders : - Preconditions : Bagian Pengawas Lapangan melakukan login dan Berita Acara Serah Terima harus tersedia dan telah di cek Postconditions : Data Rumah terupdate Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Pengawas username Lapangan melakukan 1.2 Memvalidasi login password 2. Bagian Pengawas Lapangan memilih menu Rumah 3. Bagian Pengawas Lapangan melakukan pencarian rumah 4. Bagian Pengawas Lapangan memilih rumah 5. Bagian Pengawas Lapangan mengupdate 2.1 Membuka Form Master Rumah 3.1 Menampilkan hasil pencarian 4.1 Menampilkan data Rumah -

112 Exception Conditions : status pembangunan rumah 6. Bagian Pengawas Lapangan menyimpan data Rumah - 5.1 Data Rumah tersimpan Tabel 4. 8 Use Case Description Mengecek Ketersediaan Rumah Use Case Name : Scenarios : Triggering Event : Brief Description : Mengecek Ketersediaan Rumah Bagian Marketing mengecek ketersediaan rumah karena adanya pemesanan unit rumah oleh pelanggan Calon pelanggan ingin melakukan pemesanan unit rumah Bagian Marketing melakukan login, memilih menu Rumah dan memilih Nomor Rumah Actors : Bagian Marketing Related Use Cases : - Stakeholders : - Pelanggan : untuk mengetahui apakah unit rumah yang diinginkan tersedia atau tidak Preconditions : Pelanggan melakukan pemesanan unit rumah Postconditions : Data Rumah telah di cek Flow of Events : Actor System 1. Bagian Marketing melakukan login 1.1 Memvalidasi username 1.2 Memvalidasi password Exception Conditions : 2. Bagian Marketing memilih menu Rumah 3. Bagian Marketing melakukan pencarian rumah 4. Bagian Marketing memilih rumah - 2.1 Membuka Form Master Rumah 3.1 Menampilkan hasil pencarian 4.1 Menampilkan data Rumah Use Case Name : Scenarios : Triggering Event : Tabel 4. 9 Use Case Description Menginput Data Pelanggan Menginput Data Pelanggan Bagian Marketing menginput data pelanggan setelah unit rumah yang dipesan oleh pelanggan tersedia Unit rumah yang dipesan oleh pelanggan tersedia

113 Brief Description : Actors : Related Use Cases : Stakeholders : Preconditions : Bagian Marketing melakukan login, memilih menu Pelanggan, menambah data Pelanggan baru, menginput data pelanggan, dan menyimpannya Bagian Marketing - Bagian Marketing : sebagai dasar dalam pembuatan Surat Pemesanan Rumah Pelanggan melakukan pemesanan unit rumah Postconditions : Data Pelanggan terbentuk Flow of Events : Actor System 1. Bagian Marketing melakukan login 1.1 Memvalidasi username 1.2 Memvalidasi password Exception Conditions : 2. Bagian Marketing memilih menu Pelanggan 3. Bagian Marketing menambah data pelanggan 4. Bagian Marketing menginput data pelanggan 5. Bagian Pelaksana menyimpan data pelanggan - 2.1 Membuka Form Master Pelanggan 3.1 Menampilkan Kode_Pelanggan 4.1 Memvalidasi Nama_Pelanggan 4.2 Memvalidasi NPWP 4.3 Memvalidasi No_Telepon 4.4 Memvalidasi Email 5.1 Data Pelanggan tersimpan Tabel 4. 10 Use Case Description Membuat Surat Pemesanan Rumah Use Case Name : Scenarios : Triggering Event : Brief Description : Actors : Related Use Cases : Membuat Surat Pemesanan Rumah Bagian Marketing membuat Surat Pemesanan Rumah setelah menerima uang tanda jadi (Booking Fee) dari pelanggan Pelanggan melakukan pemesanan unit rumah dan telah membayar uang tanda jadi (Booking Fee) Bagian Marketing melakukan login, memilih menu Surat Pemesanan Rumah, menambah data Surat Pemesanan Rumah baru, menginput data Surat Pemesanan Rumah, dan kemudian menyimpan dan mencetaknya Bagian Marketing -

114 Stakeholders : - Pelanggan : sebagai bukti pemesanan terhadap unit rumah - Bagian Keuangan : sebagai dasar dalam memproses pembayaran pelanggan - Bagian Akuntansi : untuk diverifikasi dengan pembayaran sebelum membuat Laporan Penerimaan Kas Preconditions : Pelanggan melakukan pemesanan unit rumah Postconditions : Surat Pemesanan Rumah terbentuk Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Marketing melakukan login username 1.2 Memvalidasi password Exception Conditions : 2. Bagian Marketing memilih menu Surat Pemesanan Rumah 3. Bagian Marketing menambah data Surat Pemesanan Rumah 4. Bagian Marketing memilih Kode Pelanggan 5. Bagian Marketing memilih Nomor Rumah 6. Bagian Marketing menginput data Surat Pemesanan Rumah 7. Bagian Marketing menyimpan Surat Pemesanan Rumah 8. Bagian Marketing mencetak Surat Pemesanan Rumah - 2.1 Membuka Form Surat Pemesanan Rumah 3.1 Menampilkan No_SPR 4.1 Menampilkan data Pelanggan 5.1 Menampilkan data Rumah 6.1 Memvalidasi Harga_Jual 6.2 Memvalidasi Nominal_Booking_ Fee 7.1 Surat Pemesanan Rumah tersimpan 8.1 Surat Pemesanan Rumah tercetak Tabel 4. 11 Use Case Description Menginput Pembayaran Tanda Jadi Use Case Name : Scenarios : Triggering Event : Menginput Pembayaran Tanda Jadi Bagian Marketing menginput Pembayaran Tanda Jadi setelah menerima pembayaran tanda jadi (booking fee) dari pelanggan Adanya pembayaran tanda jadi (Booking Fee) yang diterima dari pelanggan

115 Brief Description : Bagian Marketing melakukan login, memilih menu Pembayaran Tanda Jadi, menambah data Pembayaran Tanda Jadi baru, menginput data Pembayaran Tanda Jadi, dan menyimpannya Bagian Marketing Actors : Related Use Cases : - Stakeholders : Bagian Akuntansi : sebagai salah satu dasar dalam pembuatan Laporan Penerimaan Kas Preconditions : Bagian Marketing melakukan login dan Surat Pemesanan sudah terbentuk Postconditions : Kuitansi terbentuk Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Marketing username melakukan login 1.2 Memvalidasi password Exception Conditions : 2. Bagian Marketing memilih menu Pembayaran Tanda Jadi 3. Bagian Marketing menambah data Pembayaran Tanda Jadi 4. Bagian Marketing memilih Nomor Surat Pemesanan Rumah 5. Bagian Marketing menginput data Pembayaran Tanda Jadi 6. Bagian Marketing menyimpan Pembayaran Tanda Jadi - 2.1 Membuka Form Pembayaran Tanda Jadi 3.1 Menampilkan No_PTJ 4.1 Menampilkan data Surat Pemesanan Rumah 5.1 Memvalidasi No_Rekening 5.2 Memvalidasi Nama_Rekening 6.1 Pembayaran Tanda Jadi tersimpan Tabel 4. 12 Use Case Description Mengecek Surat Pemesanan Rumah Use Case Name : Scenarios : Triggering Event : Brief Description : Actors : Related Use Cases : Mengecek Surat Pemesanan Rumah Bagian Keuangan mengecek Surat Pemesanan Rumah yang diberikan oleh pelanggan Pelanggan ingin memproses pembayaran unit rumah Bagian Keuangan melakukan login, memilih menu Surat Pemesanan Rumah, memilih Nomor Surat Pemesanan Rumah, dan melakukan pengecekan Bagian Keuangan -

116 Stakeholders : Bagian Keuangan : untuk mengecek apakah data Surat Pemesanan Rumah yang diberikan pelanggan sudah valid Preconditions : Bagian Keuangan melakukan login dan Surat Pemesanan Rumah harus ada Postconditions : Surat Pemesanan Rumah telah di cek Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Keuangan melakukan login username 1.2 Memvalidasi password Exception Conditions : 2. Bagian Keuangan memilih menu Surat Pemesanan Rumah 3. Bagian Keuangan melakukan pencarian Surat Pemesanan Rumah 4. Bagian Keuangan memilih Surat Pemesanan Rumah - 2.1 Membuka Form Surat Pemesanan Rumah 3.1 Menampilkan hasil pencarian 4.1 Menampilkan data Surat Pemesanan Rumah Tabel 4. 13 Use Case Description Menginput Pembayaran Rumah Use Case Name : Menginput Pembayaran Rumah Scenarios : Bagian Keuangan menginput Pembayaran Rumah setelah menerima pembayaran unit rumah dari pelanggan Triggering Event : Adanya pembayaran unit rumah secara tunai yang diterima dari pelanggan dan Surat Pemesanan Rumah yang diberikan pelanggan valid Brief Description : Bagian Keuangan melakukan login, memilih menu Pembayaran Rumah, menambah data Pembayaran Rumah baru, menginput data Pembayaran Rumah, dan kemudian menyimpan dan mencetaknya Actors : Bagian Keuangan Related Use Cases : - Stakeholders : Bagian Akuntansi : sebagai salah satu dasar dalam pembuatan Laporan Penerimaan Kas Preconditions : Bagian Keuangan melakukan login dan data Surat Pemesanan Rumah harus valid Postconditions : Pembayaran Rumah terbentuk Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Keuangan username melakukan login 1.2 Memvalidasi

117 Exception Conditions : 2. Bagian Keuangan memilih menu Pembayaran Rumah 3. Bagian Keuangan menambah data Pembayaran Rumah 4. Bagian Keuangan memilih Nomor Surat Pemesanan Rumah 5. Bagian Keuangan menginput data Pembayaran Rumah 6. Bagian Keuangan menyimpan Pembayaran Rumah - password 2.1 Membuka Form Pembayaran Rumah 3.1 Menampilkan No_PR 4.1 Menampilkan data Surat Pemesanan Rumah 5.1 Memvalidasi No_Rekening 5.2 Memvalidasi Nama_Rekening 6.1 Pembayaran Rumah tersimpan Use Case Name : Scenarios : Triggering Event : Brief Description : Tabel 4. 14 Use Case Description Menginput Data KPR Menginput Data KPR Bagian Keuangan menginput data KPR setelah menerima pembayaran DP dari pelanggan Adanya pembayaran DP yang diterima dari pelanggan untuk penjualan melalui KPR Bank dan Surat Pemesanan Rumah yang diberikan pelanggan valid Bagian Keuangan melakukan login, memilih menu KPR, menambah data KPR baru, menginput data KPR, dan kemudian menyimpan dan mencetaknya Bagian Keuangan Actors : Related Use Cases : - Stakeholders : - Bank : sebagai bukti bahwa pelanggan telah melakukan pembayaran DP ke perusahaan - Bagian Akuntansi : untuk disimpan sebagai arsip perusahaan dan hanya bersifat informatif bagi perusahaan Preconditions : Bagian Keuangan melakukan login, permohonan KPR telah disetujui Bank, dan data Surat Pemesanan Rumah harus valid Postconditions : Data KPR terbentuk Flow of Events : Actor System 1. Bagian Keuangan melakukan login 1.1 Memvalidasi username 1.2 Memvalidasi password 2. Bagian Keuangan 2.1 Membuka Form

118 Exception Conditions : memilih menu KPR 3. Bagian Keuangan menambah data KPR 4. Bagian Keuangan memilih Nomor Surat Pemesanan Rumah 5. Bagian Keuangan menginput data KPR 6. Bagian Keuangan menyimpan data KPR 7. Bagian Keuangan mencetak data KPR - KPR 3.1 Menampilkan No_KPR 4.1 Menampilkan data Surat Pemesanan Rumah 5.1 Memvalidasi Nominal_DP 5.2 Memvalidasi No_Rekening 5.3 Memvalidasi Nama_Rekening 6.1 Data KPR tersimpan 7.1 Data KPR tercetak Tabel 4. 15 Use Case Description Menginput Pembayaran Cicilan KPR Use Case Name : Menginput Pembayaran Cicilan KPR Scenarios : Bagian Keuangan menginput Pembayaran Cicilan KPR pelanggan Triggering Event : Menerima bukti pembayaran cicilan KPR pelanggan dari Bank Brief Description : Bagian Keuangan melakukan login, memilih menu Pembayaran Cicilan KPR, memilih Nomor Pembayaran Cicilan KPR, menginput data Pembayaran Cicilan KPR, dan kemudian menyimpannya Actors : Bagian Keuangan Related Use Cases : - Stakeholders : - Preconditions : Bagian Keuangan melakukan login dan telah diterimanya bukti pembayaran cicilan KPR Postconditions : Pembayaran Cicilan KPR terbentuk Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Keuangan melakukan login username 1.2 Memvalidasi password 2. Bagian Keuangan memilih menu Pembayaran Cicilan KPR 3. Bagian Keuangan menambah data Pembayaran Cicilan 2.1 Membuka Form Pembayaran Cicilan KPR 3.1 Menampilkan No_PCK

119 Exception Conditions : KPR 4. Bagian Keuangan memilih Nomor KPR 5. Bagian Keuangan menginput data Pembayaran Cicilan KPR 6. Bagian Keuangan menyimpan Pembayaran Cicilan KPR - 4.1 Menampilkan Tanggal_KPR 5.1 Memvalidasi Nominal_ Pembayaran 6.1 Pembayaran Cicilan KPR tersimpan Tabel 4. 16 Use Case Description Membuat Surat Perjanjian Jual Beli Use Case Name : Membuat Surat Perjanjian Jual Beli Scenarios : Bagian Keuangan membuat Surat Perjanjian Jual Beli setelah kredit in house pelanggan disetujui Triggering Event : Kredit in house pelanggan telah disetujui dan Surat Pemesanan Rumah yang diberikan pelanggan valid Brief Description : Bagian Keuangan melakukan login, memilih menu Surat Perjanjian Jual Beli, menambah data Surat Perjanjian Jual Beli baru, menginput data Surat Perjanjian Jual Beli, dan kemudian menyimpan dan mencetakanya Actors : Bagian Keuangan Related Use Cases : - Stakeholders : Pelanggan : sebagai tanda konfirmasi bahwa pelanggan telah setuju dengan kesepakatan kredit in house Preconditions : Bagian Keuangan melakukan login, kredit in house pelanggan telah disetujui, dan SPR pelanggan harus valid Postconditions : Surat Perjanjian Jual Beli terbentuk Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Keuangan melakukan login username 1.2 Memvalidasi password 2. Bagian Keuangan memilih menu Surat Perjanjian Jual Beli 3. Bagian Keuangan menambah data Surat Perjanjian Jual Beli 4. Bagian Keuangan menginput data Surat Perjanjian Jual Beli 2.1 Membuka Form Surat Perjanjian Jual Beli 3.1 Menampilkan No_SPJB -

120 Exception Conditions : 5. Bagian Keuangan memilih Nomor Surat Pemesanan Rumah 6. Bagian Keuangan memilih Kode Pelanggan 7. Bagian Keuangan menyimpan Surat Perjanjian Jual Beli 8. Bagian Keuangan mencetak Surat Perjanjian Jual Beli - 5.1 Menampilkan data Surat Pemesanan Rumah 6.1 Menampilkan Nama_Pelanggan 6.2 Menampilkan Tanggal_Lahir 6.3 Menampilkan No_KTP 6.4 Menampilkan Alamat 6.5 Menampilkan No_Telepon 7.1 Surat Perjanjian Jual Beli tersimpan 8.1 Surat Perjanjian Jual Beli tercetak Tabel 4. 17 Use Case Description Menginput Pembayaran Cicilan Rumah Use Case Name : Scenarios : Triggering Event : Brief Description : Menginput Pembayaran Cicilan Rumah Bagian Keuangan menginput Pembayaran Cicilan Rumah setelah menerima Surat Perjanjian Jual Beli yang telah ditantangani Adanya Surat Perjanjian Jual Beli yang telah ditandatangani oleh pelanggan Bagian Keuangan melakukan login, memilih menu Pembayaran Cicilan Rumah, menambah data Pembayaran Cicilan baru, menginput data Pembayaran Cicilan Rumah, dan menyimpannya Bagian Keuangan Actors : Related Use Cases : - Stakeholders : - Bagian Keuangan : untuk memberikan notifikasi tanggal jatuh tempo dari piutang pelanggan - Bagian Akuntansi : sebagai salah satu dasar dalam pembuatan Laporan Penerimaan Kas Preconditions : Bagian Keuangan melakukan login dan telah menerima Surat Perjanjian Jual Beli yang telah ditandatangani oleh pelanggan Postconditions : Pembayaran Cicilan Rumah terbentuk Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Keuangan melakukan login username 1.2 Memvalidasi password 2. Bagian Keuangan 2.1 Membuka Form

121 Exception Conditions : memilih menu Pembayaran Cicilan Rumah 3. Bagian Keuangan menambah data Pembayaran Cicilan Rumah 4. Bagian Keuangan memilih Nomor Surat Perjanjian Jual Beli 5. Bagian Keuangan menginput data Pembayaran Cicilan Rumah 6. Bagian Keuangan menyimpan Pembayaran Cicilan Rumah - Pembayaran Cicilan Rumah 3.1 Menampilkan No_PCR 4.1 Menampilkan No_SPJB 4.2 Menampilan Harga_Jual 5.1 Memvalidasi Nominal_Cicilan 5.2 Memvalidasi No_Rekening 5.3 Memvalidasi Nama_Rekening 6.1 Pembayaran Cicilan Rumah tersimpan Tabel 4. 18 Use Case Description Membuat Faktur Penagihan Use Case Name : Scenarios : Triggering Event : Brief Description : Membuat Faktur Penagihan Bagian Keuangan membuat Faktur Penagihan setelah menerima notifikasi dari sistem Piutang pelanggan akan jatuh tempo Bagian Keuangan melakukan login, memilih menu Faktur Penagihan,menambah data Faktur Penagihan baru, menginput data Faktur Penagihan, dan kemudian menyimpan dan mencetakanya Bagian Keuangan Actors : Related Use Cases : - Stakeholders : - Pelanggan : sebagai dasar pembayaran cicilan - Bagian Penagihan : sebagai dasar dalam melakukan penagihan dan bukti bahwa penagihan telah dilakukan - Bagian Akuntansi : untuk diverifikasi dengan pembayaran sebelum membuat Laporan Piutang Preconditions : Bagian Keuangan melakukan login dan telah menerima notifikasi bahwa piutang pelanggan akan jatuh tempo Postconditions : Faktur Penagihan terbentuk Flow of Events : Actor System 1. Bagian Keuangan 1.1 Memvalidasi

122 Exception Conditions : melakukan login 2. Bagian Keuangan memilih menu Faktur Penagihan 3. Bagian Keuangan menambah data Faktur Penagihan 4. Bagian Keuangan memilih Nomor Pembayaran Cicilan Rumah 5. Bagian Keuangan menginput data Faktur Penagihan 6. Bagian Keuangan menyimpan Faktur Penagihan 7. Bagian Keuangan mencetak Faktur Penagihan - username 1.2 Memvalidasi password 2.1 Membuka Form Faktur Penagihan 3.1 Menampilkan No_FakturPenagihan 4.1 Menampilkan data Pembayaran Cicilan Rumah 6.1 Faktur Penagihan tersimpan 7.1 Faktur Penagihan tercetak - Tabel 4. 19 Use Case Description Mengupdate Pembayaran Cicilan Rumah Use Case Name : Scenarios : Triggering Event : Brief Description : Mengupdate Pembayaran Cicilan Rumah Bagian Keuangan mengupdate Pembayaran Cicilan Rumah pada sistem Telah diterimanya Faktur Penagihan yang telah ditandatangani dan pembayaran cicilan rumah dari pelanggan Bagian Keuangan melakukan login, memilih menu Pembayaran Cicilan Rumah, mengupdate data Pembayaran Cicilan Rumah, dan kemudian menyimpannya Bagian Keuangan Actors : Related Use Cases : - Stakeholders : - Bagian Keuangan : untuk menyatakan bahwa pembayaran sudah lunas - Bagian Akuntansi :sebagai salah satu dasar dalam pembuatan Laporan Penerimaan Kas Preconditions : Bagian Keuangan melakukan login dan telah menerima pelunasan cicilan rumah dari pelanggan Postconditions : Pembayaran Cicilan Rumah terupdate Flow of Events : Actor System 1. Bagian Keuangan 1.1 Memvalidasi

123 Exception Conditions : melakukan login 2. Bagian Keuangan memilih menu Pembayaran Cicilan Rumah 3. Bagian Keuangan melakukan pencarian Pembayaran Cicilan Rumah 4. Bagian Keuangan memilih Nomor Pembayaran Cicilan Rumah 5. Bagian Keuangan mengupdate data Pembayaran Cicilan Rumah 6. Bagian Keuangan mengganti status dari open ke closed 7. Bagian Keuangan menyimpan Pembayaran Cicilan username 1.2 Memvalidasi password 2.1 Membuka Form Pembayaran Cicilan Rumah 3.1 Menampilkan hasil pencarian 4.1 Menampilkan data Pembayaran Cicilan Rumah 5.1 Memvalidasi No_Rekening 5.2 Memvalidasi Nama_Rekening 7.1 Pembayaran Cicilan Rumah tersimpan Rumah 5.1 Hanya jika pelanggan sudah melunasi semua pembayaran cicilan rumah - Tabel 4. 20 Use Case Description Membuat Progress Kerja Mingguan Use Case Name : Scenarios : Triggering Event : Brief Description : Actors : Related Use Cases : Stakeholders : Preconditions : Postconditions : Membuat Progress Kerja Mingguan Bagian Pengawas Lapangan membuat Progress Kerja Mingguan setelah melakukan pengawasan terhadap pekerjaan pembangunan Akhir Minggu Bagian Pengawas Lapangan melakukan login, memilih menu Progress Kerja Mingguan, menginput periode yang diinginkan, menginput data Progress Kerja Mingguan, dan kemudian menyimpan dan mencetaknya Bagian Pengawas Lapangan - Manajer Umum : diberikan sebagai laporan mingguan terhadap mengenai progress pembangunan Bagian Pengawas Lapangan melakukan login pada akhir minggu Progress Kerja Mingguan terbentuk

124 Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Pengawas username Lapangan melakukan 1.2 Memvalidasi login password Exception Conditions : 2. Bagian Pengawas Lapangan memilih menu Progress Kerja Mingguan 3. Bagian Keuangan menambah data Progress Kerja Mingguan 4. Bagian Pengawas Lapangan menginput periode yang diinginkan 5. Bagian Pengawas Lapangan memilih Nomor Surat Perintah Kerja 6. Bagian Pengawas Lapangan menginput data Progress Kerja Mingguan 7. Bagian Pengawas Lapangan menyimpan Progress Kerja Mingguan 8. Bagian Pengawas Lapangan mencetak Progress Kerja Mingguan - 2.1 Membuka Form Progress Kerja Mingguan 3.1 Menampilkan No_PKM - 5.1 Menampilkan data Surat Perintah Kerja 7.1 Progress Kerja Mingguan tersimpan 8.1 Progress Kerja Mingguan tercetak - Tabel 4. 21 Use Case Description Generate Laporan Hasil Kerja Use Case Name : Scenarios : Triggering Event : Brief Description : Actors : Related Use Cases : Stakeholders : Generate Laporan Hasil Kerja Bagian Pengawas Lapangan membuat Laporan Hasil Kerja setelah pembangunan selesai Unit rumah telah selesai dibangun Bagian Pengawas Lapangan melakukan login, memilih menu Laporan Hasil Kerja, menginput periode yang diinginkan, dan kemudian mencetaknya Bagian Pengawas Lapangan - Manajer Umum : diberikan sebagai salah satu laporan

125 pada akhir proyek pembangunan Preconditions : Bagian Pengawas Lapangan melakukan login pada saat pembangunan telah selesai Postconditions : Laporan Hasil Kerja terbentuk Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Pengawas username Lapangan melakukan 1.2 Memvalidasi login password Exception Conditions : 2. Bagian Pengawas Lapangan memilih menu Laporan Hasil Kerja 3. Bagian Pengawas Lapangan menginput periode yang diinginkan 4. Bagian Pengawas Lapangan mencetak Laporan Hasil Kerja - 2.1 Membuka Form Laporan Hasil Kerja - 4.1 Laporan Hasil Kerja tercetak Tabel 4. 22 Use Case Description Generate Laporan Pemesanan Rumah Use Case Name : Scenarios : Triggering Event : Brief Description : Actors : Related Use Cases : Stakeholders : Preconditions : Generate Laporan Pemesanan Rumah Bagian Marketing membuat Laporan Pemesanan Rumah di akhir bulan Akhir Bulan Bagian Marketing melakukan login, memilih menu Laporan Pemesanan Rumah, menginput periode yang diinginkan, dan kemudian mencetaknya Bagian Marketing - Manajer Umum : diberikan sebagai salah satu laporan bulanan Bagian Marketing melakukan login di akhir bulan Postconditions : Laporan Pemesanan Rumah terbentuk Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Marketing melakukan login username 1.2 Memvalidasi password 2. Bagian Marketing memilih menu Laporan Pemesanan Rumah 2.1 Membuka Form Laporan Pemesanan Rumah

126 Exception Conditions : 3. Bagian Marketing menginput periode yang diinginkan 4. Bagian Marketing mencetak Laporan Pemesanan Rumah - 4.1 Laporan Pemesanan Rumah tercetak - Tabel 4. 23 Use Case Description Membuat Laporan Piutang Use Case Name : Scenarios : Triggering Event : Brief Description : Actors : Related Use Cases : Stakeholders : Preconditions : Generate Laporan Piutang Bagian Akuntansi membuat Laporan Piutang Akhir Bulan Bagian Akuntansi melakukan login, memilih menu Laporan Piutang, memilih periode yang diinginkan, dan mencetaknya Bagian Akuntansi - Manajer Umum : diberikan sebagai salah satu laporan bulanan Bagian Akuntansi melakukan login di akhir bulan Postconditions : Laporan Piutang terbentuk Flow of Events : Actor System 1. Bagian Akuntansi melakukan login 1.1 Memvalidasi username 1.2 Memvalidasi password Exception Conditions : 2. Bagian Akuntansi memilih menu Laporan Piutang 3. Bagian Akuntansi menginput periode yang diinginkan 4. Bagian Akuntansi mencetak Laporan Piutang - 2.1 Membuka Form Laporan Piutang 4.1 Laporan Piutang tercetak - Tabel 4. 24 Use Case Description Generate Laporan Penerimaan Kas Use Case Name : Generate Laporan Penerimaan Kas Scenarios : Bagian Akuntansi membuat Laporan Penerimaan Kas di akhir bulan Triggering Event Akhir Bulan

127 : Brief Description : Actors : Related Use Cases : Stakeholders : Preconditions : Bagian Akuntansi melakukan login, memilih menu Laporan Penerimaan Kas, menginput periode yang diinginkan, dan mencetaknya Bagian Akuntansi - Manajer Umum : diberikan sebagai salah satu laporan bulanan Bagian Akuntansi melakukan login di akhir bulan Postconditions : Laporan Penerimaan Kas terbentuk Flow of Events : Actor System 1.1 Memvalidasi 1. Bagian Akuntansi melakukan login username 1.2 Memvalidasi password Exception Conditions : 2. Bagian Akuntansi memilih menu Laporan Penerimaan Kas 3. Bagian Akuntansi menginput periode yang diinginkan 4. Bagian Akuntansi mencetak Laporan Penerimaan Kas - 2.1 Membuka Form Laporan Penerimaan Kas 4.1 Laporan Penerimaan Kas tercetak - Use Case Name : Scenarios : Triggering Event : Brief Description : Actors : Related Use Cases : Stakeholders : Preconditions : Tabel 4. 25 Use Case Description Generate Laporan Jurnal Generate Laporan Jurnal Bsgian Akuntansi membuat Laporan Jurnal di akhir bulan Akhir Bulan Bagian Akuntansi melakukan login, memilih menu Laporan Jurnal, menginput periode yang diinginkan, dan mencetaknya Bagian Akuntansi - Manajer Umum : diberikan sebagai salah satu laporan bulanan Bagian Akuntansi melakukan login di akhir bulan Postconditions : Laporan Jurnal terbentuk Flow of Events : Actor System 1. Bagian Akuntansi 1.1 Memvalidasi

128 Exception Conditions : melakukan login 2. Bagian Akuntansi memilih menu Laporan Jurnal 3. Bagian Akuntnasi menginput periode yang diinginkan 4. Bagian Akuntansi mencetak Laporan Jurnal - username 1.2 Memvalidasi password 2.1 Menampilkan Laporan Jurnal 4.1 Mencetak Laporan Jurnal -

129 4.2.4 Domain Model Class Diagram Gambar 4. 9 Domain Model Class Diagram

130 4.3 Use Case Modeling and Detailed Requirements 4.3.1 Statechart Diagram Gambar 4. 10 Statechart Diagram Karyawan Gambar 4. 11 Statechart Diagram Rumah Gambar 4. 12 Statechart Diagram Pelanggan Gambar 4. 13 Statechart Diagram Bank

131 Gambar 4. 14 Statechart Diagram Surat Perimtah Mulai Bangun Gambar 4. 15 Statechart Diagram Surat Perintah Kerja Gambar 4. 16 Statechart Diagram Berita Acara Serah Terima

132 Gambar 4. 17 Statechart Diagram Progress Kerja Mingguan Gambar 4. 18 Statechart Diagram Surat Pemesanan Rumah Gambar 4. 19 Statechart Diagram Pembayaran Tanda Jadi

133 Gambar 4. 20 Statechart Diagram Pembayaran Rumah Gambar 4. 21 Statechart Diagram KPR Gambar 4. 22 Statechart Diagram Pembayaran Cicilan KPR

134 Gambar 4. 23 Statechart Diagram Surat Perjanjian Jual Beli Gambar 4. 24 Statechart Diagram Pembayaran Cicilan Rumah Gambar 4. 25 Statechart Diagram Faktur Penagihan

135 4.3.2 System Sequence Diagram Gambar 4. 26 System Sequence Diagram Menginput Data Rumah

136 Gambar 4. 27 System Sequence Diagram Membuat Surat Perintah Mulai Bangun

Gambar 4. 28 System Sequence Diagram Membuat Surat Perintah Kerja 137

138 Gambar 4. 29 System Sequence Diagram Membuat Berita Acara Serah Terima

139 Gambar 4. 30 System Sequence Diagram Mengupdate Data Rumah Gambar 4. 31 System Sequence Diagram Mengecek Ketersediaan Rumah

140 Gambar 4. 32 System Sequence Diagram Menginput Data Pelanggan

Gambar 4. 33 System Sequence Diagram Membuat Surat Pemesanan Rumah 141

142 Gambar 4. 34 System Sequence Diagram Menginput Pembayaran Tanda Jadi Gambar 4. 35 System Sequence Diagram Mengecek Surat Pemesanan Rumah

Gambar 4. 36 System Sequence Diagram Menginput Pembayaran Rumah 143

144 Gambar 4. 37 System Sequence Diagram Menginput Data KPR

Gambar 4. 38 System Sequence Diagram Menginput Pembayaran Cicilan KPR 145

146 Gambar 4. 39 System Sequence Diagram Membuat Surat Perjanjian Jual Beli

Gambar 4. 40 System Sequence Diagram Menginput Pembayaran Cicilan Rumah 147

148 Gambar 4. 41 System Sequence Diagram Membuat Faktur Penagihan

Gambar 4. 42 System Sequence Diagram Membuat Progress Kerja Mingguan 149

150 Gambar 4. 43 System Sequence Diagram Generate Laporan Hasil Kerja Gambar 4. 44 System Sequence Diagram Generate Laporan Pemesanan Rumah

151 Gambar 4. 45 System Sequence Diagram Generate Laporan Piutang Gambar 4. 46 System Sequence Diagram Generate Laporan Penerimaan Kas

152 Gambar 4. 47 System Sequence Diagram Generate Laporan Jurnal

153 4.4 Design Discipline 4.4.1 First-cut Design Model Class Diagram Gambar 4. 48 First-cut Design Model Class Diagram

154 4.4.2 Completed Three-layer Design Sequence Diagram Gambar 4. 49 Completed Three-layer Design Sequence Diagram Create Rumah

155 Sd View Rumah <<boundary>> :RumahWindow :Rumah Handler :Rumah :Rumah DA :SpesifikiasiTeknis :SpesifikasiTeknis DA Arsitek Open_Rumah() Open_Rumah() Init_Rumah() Read_Rumah() Init_SpesifikasiTeknis() Read_SpesifikasiTeknis() Alt View Search_Rumah(No_Rumah) Search_Rumah(No_Rumah) get_datarumah(no_rumah) No_Rumah,No_Spesifikasi, Tipe,Harga_Jual,Status_ Pembangunan,Status_ Ketersediaan Select_Rumah(No_Rumah) No_Rumah,No_Spesifikasi, Tipe,Harga_Jual,Status_ Pembangunan,Status_ Ketersediaan Select_Rumah(No_Rumah) get_datarumah(no_rumah) No_Rumah,Tipe,Harga_ Jual,Status_Pembangunan, Status_Ketersediaan get_dataspesifikasi(no_spesifikasi) No_Rumah,Tipe,Harga_ Jual,Status_Pembangunan, Status_Ketersediaan, No_Spesifikasi,Pondasi, Dinding,Lantai,Penutup_Atap, Pintu,Kusen,Jendela,Plafon,Sanitary,Air,Daya_ Listrik,Carport No_Spesifikasi,Pondasi,Dinding,Lantai,Penutup_ Atap,Pintu,Kusen,Jendela,Plafon,Sanitary,Air,Daya _Listrik,Carport Opt Update Update_Rumah() update_datarumah(tipe, Harga_Jual,Status_ Pembangunan,Status_ Ketersediaan Update_Rumah() update_datarumah(tipe, Harga_Jual,Status_ Pembangunan,Status_ Ketersediaan Update_Rumah() update_datarumah(tipe, Harga_Jual,Status_ Pembangunan,Status_ Ketersediaan Opt Update Spesifikasi update_dataspesifikasi (Pondasi,Dinding,Lantai, Penutup_Atap,Pintu,Kusen,Jendela,Plafon,Sanitary, Air,Daya_Listrik,Carport update_dataspesifikasi (Pondasi,Dinding,Lantai, Penutup_Atap,Pintu,Kusen,Jendela,Plafon,Sanitary, Air,Daya_Listrik,Carport update_dataspesifikasi(pondasi,dinding,lantai, Penutup_Atap,Pintu,Kusen,Jendela,Plafon,Sanitary, Air,Daya_Listrik,Carport Save() Save() Save() Save() Save() Save() Opt Cancel Cancel() Cancel() Cancel() Gambar 4. 50 Completed Three-layer Design Sequence Diagram View Rumah

156 Gambar 4. 51 Completed Three-layer Design Sequence Diagram Create SPMB

Gambar 4. 52 Completed Three-layer Design Sequence Diagram View SPMB 157

158 Gambar 4. 53 Completed Three-layer Design Sequence Diagram Create SPK

Gambar 4. 54 Completed Three-layer Design Sequence Diagram View SPK 159

160 Gambar 4. 55 Completed Three-layer Design Sequence Diagram Create BAST

Gambar 4. 56 Completed Three-layer Design Sequence Diagram View BAST 161

162 Gambar 4. 57 Completed Three-layer Design Sequence Diagram Update Status Pembangunan Rumah

Gambar 4. 58 Completed Three-layer Design Sequence Diagram Mengecek Ketersediaan Rumah 163

164 Gambar 4. 59 Completed Three-layer Design Sequence Diagram Create Pelanggan

Gambar 4. 60 Completed Three-layer Design Sequence Diagram View Pelanggan 165

166 Gambar 4. 61 Completed Three-layer Design Sequence Diagram Create SPR

Gambar 4. 62 Completed Three-layer Design Sequence Diagram View SPR 167

168 Gambar 4. 63 Completed Three-layer Design Sequence Diagram Create PTJ

169 Sd View Pembayaran Tanda Jadi (PTJ) <<boundary>> :PTJWindow :PTJ Handler :PTJ :PTJ DA :SPR :SPR DA :Bank :Bank DA Bagian Marketing Open_PTJ() Open_PTJ() Init_PTJ() Read_PTJ() Init_SPR() Read_SPR() Init_Bank() Read_Bank() Alt View Search_PTJ(No_PTJ) Search_PTJ(No_PTJ) get_dataptj(no_ptj) No_PTJ,Tanggal_PTJ,No_ SPR,Nominal_Booking_Fee,Jenis_Penerimaan,Kode_ Bank,No_Bukti,No_ Rekening,Nama_Rekening No_PTJ,Tanggal_PTJ,No_ SPR,Nominal_Booking_Fee,Jenis_Penerimaan,Kode_ Bank,No_Bukti,No_ Rekening,Nama_Rekening Select_PTJ(No_PTJ) Select_PTJ(No_PTJ) get_dataptj(no_ptj) No_PTJ,Tanggal_PTJ,Jenis _Penerimaan,No_Bukti,No_ Rekening,Nama_Rekening No_PTJ,Tanggal_PTJ,Jenis _Penerimaan,No_Bukti,No_ Rekening,Nama_Rekening get_dataspr(no_spr) No_SPR,Tanggal_SPR, Kode_Pelanggan,No_ Rumah,Harga_Jual, Metode_Pembayaran, Nominal_Booking_Fee No_SPR,Tanggal_SPR,Kode_Pelanggan,No_Rumah,Harga_Jual,Metode_ Pembayaran,Nominal_Booking_Fee get_databank(kode_bank) Kode_Bank,Nama_Bank Kode_Bank,Nama_Bank Opt Update Update_PTJ() update_dataptj(tanggal_ PTJ,Jenis_Penerimaan,No_ Bukti,No_Rekening,Nama _Rekening) Update_PTJ() update_dataptj(tanggal_ PTJ,Jenis_Penerimaan,No_ Bukti,No_Rekening,Nama _Rekening) Update_PTJ() update_dataptj(tanggal_ PTJ,Jenis_Penerimaan,No_ Bukti,No_Rekening,Nama _Rekening) Opt Update SPR Select_SPR(No_SPR) Select_SPR(No_SPR) get_dataspr(no_spr) No_SPR,Tanggal_SPR, Kode_Pelanggan,No_ Rumah,Harga_Jual, Metode_Pembayaran, Nominal_Booking_Fee No_SPR,Tanggal_SPR,Kode_Pelanggan,No_Rumah,Harga_Jual,Metode_ Pembayaran,Nominal_Booking_Fee Opt Update Bank Select_Bank(Kode_Bank) Select_Bank(Kode_Bank) get_databank(kode_bank) Kode_Bank,Nama_Bank Kode_Bank,Nama_Bank Save() Save() Save() Save() Opt Delete Delete() Delete() Delete() Delete() Opt Cancel Cancel() Cancel() Cancel() Gambar 4. 64 Completed Three-layer Design Sequence Diagram View PTJ

170 Gambar 4. 65 Completed Three-layer Design Sequence Diagram Mengecek Validitas SPR

Gambar 4. 66 Completed Three-layer Design Sequence Diagram Create PR 171

172 Gambar 4. 67 Completed Three-layer Design Sequence Diagram View PR

Gambar 4. 68 Completed Three-layer Design Sequence Diagram Create KPR 173

174 Gambar 4. 69 Completed Three-layer Design Sequence Diagram View KPR

Gambar 4. 70 Completed Three-layer Design Sequence Diagram Create PCK 175

176 Gambar 4. 71 Completed Three-layer Design Sequence Diagram View PCK

Gambar 4. 72 Completed Three-layer Design Sequence Diagram Create SPJB 177

178 Gambar 4. 73 Completed Three-layer Design Sequence Diagram View SPJB

Gambar 4. 74 Completed Three-layer Design Sequence Diagram Create PCR 179

180 Gambar 4. 75 Completed Three-layer Design Sequence Diagram View PCR

Gambar 4. 76 Completed Three-layer Design Sequence Diagram Create Faktur Penagihan 181

182 Gambar 4. 77 Completed Three-layer Design Sequence Diagram View Faktur Penagihan

Gambar 4. 78 Completed Three-layer Design Sequence Diagram Create Progress Kerja Mingguan 183

184 Gambar 4. 79 Completed Three-layer Design Sequence Diagram View Progress Kerja Mingguan

185 Gambar 4. 80 Completed Three-layer Design Sequence Diagram Generate Laporan Hasil Kerja Gambar 4. 81 Completed Three-layer Design Sequence Diagram Generate Laporan Pemesanan Rumah

186 Gambar 4. 82 Completed Three-layer Design Sequence Diagram Generate Laporan Piutang

Gambar 4. 83 Completed Three-layer Design Sequence Diagram Generate Laporan Penerimaan Kas 187

188 Gambar 4. 84 Completed Three-layer Design Sequence Diagram Generate Laporan Jurnal Gambar 4. 85 Completed Three-layer Design Sequence Diagram Post Jurnal

189 4.4.3 Updated Design Class Diagram Gambar 4. 86 Updated Design Class Diagram

190 4.4.4 Package Diagram Gambar 4. 87 Package Diagram

191 4.4.5 UI Storyboard Gambar 4. 88 UI Storyboard Menu File

192 Gambar 4. 89 UI Storyboard Pembangunan Unit Rumah

Gambar 4. 90 UI Storyboard Transaksi 193

194 Gambar 4. 91 UI Storyboard Laporan

195 4.4.6 Design the User Interface 4.4.6.1 User Interface Windows Menu Utama Gambar 4. 92 User Interface Windows Menu Utama Ketika sistem digunakan, maka yang pertama akan muncul adalah Menu Utama. Menu Utama terdiri dari beberapa menu item, antara lain : 1. Menu File Setelah login ke dalam sistem, user dapat menggunakan menu ini untuk melakukan penggantian password atau untuk logout dari sistem. 2. Menu Master User dapat menggunakan menu ini untuk mengakses data-data pada Form Master, yang terdiri dari Form Master Karyawan, Form Master Rumah, Form Master Pelanggan, dan Form Master Bank. 3. Menu Pembangunan User dapat menggunakan menu ini untuk mengakses data-data Form yang berkaitan dengan kegiatan pembangunan unit rumah, yang terdiri dari Form Surat Perintah Mulai Bangun, Form Surat Perintah Kerja, Form Berita Acara Serah Terima, dan Form Progress Kerja Mingguan.

196 4. Menu Transaksi User dapat menggunakan menu ini untuk mengakses data-data Form yang berkaitan dengan kegiatan penjualan unit rumah, yang terdiri dari Form Surat Pemesanan Rumah, Form Pembayaran Tanda Jadi, Form Pembayaran Rumah, Form KPR, Form Pembayaran Cicilan KPR, Form Surat Perjanjian Jual Beli, Form Pembayaran Cicilan Rumah, dan Form Faktur Penagihan. 5. Menu Laporan User dapat menggunakan menu ini untuk mengakses data-data Form yang berkaitan dengan kegiatan pelaporan, yang terdiri dari Form Laporan Hasil Kerja, Form Laporan Pemesanan Rumah, Form Laporan Piutang, Form Laporan Penerimaan Kas, dan Form Laporan Jurnal. Gambar 4. 93 User Interface Windows Menu File Ketika Menu File diklik, maka akan muncul beberapa sub menu, antara lain sebagai berikut : 1. Login, digunakan ketika user mulai menggunakan sistem. 2. Ganti Password, digunakan ketika user ingin mengganti password yang lama dengan password yang baru. Form ini dapat digunakan setelah user melakukan login. 3. Logout, digunakan ketika user ingin mengakhiri penggunaan sistem. Gambar 4. 94 User Interface Windows Menu Master

197 Ketika Menu Master diklik, maka akan muncul beberapa sub menu, antara lain sebagai berikut : 1. Karyawan, digunakan ketika user ingin mengakses, menambah, atau mengubah data-data karyawan perusahaan. 2. Rumah, digunakan ketika user ingin mengakses, menambah, atau mengubah data-data unit rumah yang dimiliki oleh perusahaan. 3. Pelanggan, digunakan ketik user ingin mengakses, menambah, atau mengubah data-data pelanggan. 4. Bank, digunakan ketika user ingin mengakses, menambah, atau mengubah datadata Bank. Gambar 4. 95 User Interface Windows Menu Pembangunan Ketika Menu Pembangunan diklik, maka akan muncul beberapa sub menu, antara lain sebagai berikut : 1. Surat Perintah Mulai Bangun, digunakan ketika user ingin mengakses, menambah, mengubah, menghapus, atau mencetak data-data SPMB. Data-data pada form ini akan di input oleh Manajer Umum untuk memulai proyek pembangunan unit rumah. 2. Surat Perintah Kerja, digunakan ketika user ingin mengakses, menambah, mengubah, menghapus, atau mencetak data-data SPK. Data-data pada form ini akan di input oleh Bagian Keuangan berdasarkan Surat Perintah Mulai Bangun yang telah dibuat oleh Manajer Umum dan ditujukan untuk Bagian Pengawas Lapangan dan Bagian Pelaksana. 3. Berita Acara Serah Terima, digunakan ketika user ingin menghapus, menambah, menghapus, atau mencetak data-data BAST. Data-data pada form ini di input oleh Bagian Pelaksana ketika proyek pembangunan telah selesai.

198 4. Progress Kerja Mingguan, digunakan ketika user ingin mengakses, menambah, mengubah, menghapus, atau mencetak data-data Progress Kerja Mingguan. Setiap minggu, form ini di input oleh Bagian Pengawas Lapangan untuk mencatat progress pekerjaan proyek pembangunan di lapangan. Gambar 4. 96 User Interface Windows Menu Transaksi Ketika Menu Transaksi diklik, maka akan muncul beberapa sub menu, antara lain sebagai berikut : 1. Surat Pemesanan Rumah, digunakan ketika user ingin mengakses, menambah, mengubah, menghapus, atau mencetak data-data SPR. Data-data pada form ini di input oleh Bagian Marketing ketika menerima pemesanan unit rumah dari pelanggan. 2. Pembayaran Tanda Jadi, digunakan ketika user ingin mengakses, menambah, mengubah, atau menghapus data-data Pembayaran Tanda Jadi. Data-data pada form ini di input oleh Bagian Marketing setelah menerima pembayaran uang tanda jadi (booking fee) dari pelanggan. 3. Pembayaran Rumah, digunakan ketika user ingin mengkases, menambah, mengubah, atau menghapus data-data Pembayaran Rumah. Form ini digunakan untuk penjualan unit rumah secara tunai dan data-data pada form ini di input oleh Bagian Keuangan setelah menerima pembayaran unit rumah dari pelanggan. 4. KPR, digunakan ketika user ingin mengakses, menambah, mengubah, menghapus, atau mencetak data-data KPR pelanggan. Form ini digunakan untuk penjualan unit rumah melalui KPR Bank dan data-data pada form ini di input oleh Bagian Keuangan setelah pelanggan melakukan pembayaran uang muka (DP) ke perusahaan. 5. Pembayaran Cicilan KPR, digunakan ketika user ingin mengakses, menambah, mengubah, atau menghapus data-data Pembayaran Cicilan KPR. Data-data pada

199 form ini di input oleh Bagian Keuangan ketika menerima bukti pembayaran cicilan KPR pelanggan dari Bank dan akan di update setiap bulannya untuk menginput pembayaran cicilan KPR yang telah dibayar oleh pelanggan ke Bank. 6. Surat Perjanjian Jual Beli, digunakan ketika user ingin mengakses, menambah, mengubah, menghapus, atau mencetak data-data SPJB. Form ini digunakan untuk penjualan kredit in house dan berfungsi sebagai kesepakatan kredit antara pelanggan dengan perusahaan. Data-data pada form ini di input oleh Bagian Keuangan setelah kredit in house pelanggan disetujui oleh perusahaan. 7. Pembayaran Cicilan Rumah, digunakan ketika user ingin mengakses, menambah, mengubah, atau menghapus data-data Pembayaran Cicilan Rumah. Data-data pada form ini di input oleh Bagian Keuangan setelah menerima pembayaran cicilan pertama dari pelanggan dan akan di update setiap menerima pelunasan pembayaran cicilan rumah dari pelanggan. 8. Faktur Penagihan, digunakan ketika user ingin mengakses, menambah, mengubah, menghapus, atau mencetak data-data Faktur Penagihan. Data-data pada form ini di input oleh Bagian Keuangan ketika akan melakukan penagihan cicilan rumah ke pelanggan. Gambar 4. 97 User Interface Windows Menu Laporan Ketika Menu Laporan diklik, maka akan muncul beberapa submenu, antara lain sebagai berikut : 1. Laporan Hasil Kerja, digunakan oleh Bagian Pengawas Lapangan ketika proyek pembangunan unit rumah telah selesai. Laporan Hasil Kerja berasal dari Progress Kerja Mingguan. 2. Laporan Pemesanan Rumah, digunakan oleh Bagian Marketing untuk melaporkan pemesanan unit rumah dari pelanggan setiap bulannya. Laporan Pemesanan Rumah berasal dari Surat Pemesanan Rumah.

200 3. Laporan Piutang, digunakan oleh Bagian Akuntansi untuk melaporkan data piutang pelanggan setiap bulannya. Laporan Piutang berasal dari Faktur Penagihan. 4. Laporan Penerimaan Kas, digunakan oleh Bagian Akuntansi untuk melaporkan kas yang diterima oleh perusahaan setiap bulannya. Laporan Penerimaan Kas dapat berasal dari Pembayaran Tanda Jadi, Pembayaran Rumah, KPR, atau Pembayaran Cicilan Rumah. 5. Laporan Jurnal, digunakan oleh Bagian Akuntansi untuk melaporkan jurnaljurnal yang telah ter-generate secara otomatis oleh sistem setiap bulannya. 4.4.6.2 User Interface Form Login Gambar 4. 98 User Interface Form Login Form Login digunakan ketika user mulai menggunakan sistem. Untuk dapat menggunakan sistem, user harus terlebih dahulu memasukkan Kode Karyawan dan Password. Jika user salah dalam memasukkan Kode Karyawan atau password, maka sistem akan menampilkan messagebox seperti berikut : Gambar 4. 99 Messagebox Salah dalam Memasukkan Kode Karyawan dan Password

201 Sedangkan jika user memasukkan Kode Karyawan dan password yang benar, maka user akan masuk ke dalam sistem dan sistem akan menampilkan Menu Utama. 4.4.6.3 User Interface Form Penggantian Password Gambar 4. 100 User Interface Form Penggantian Password Form Penggantian Password digunakan ketika user ingin mengganti password yang lama dengan password yang baru. User terlebih dahulu menginput password yang lama, kemudian menginput password yang baru. Format password adalah minimal 5 karakter dan maksimal 12 karakter yang berupa kombinasi antara angka dan huruf. Input password dilakukan sebanyak dua kali sebagai konfirmasi atas password yang dipilih. Jika user dalam menginput password yang lama, sistem akan memunculkan pesan Password yang Anda Masukkan Salah. Jika konfirmasi password yang di input user berbeda dengan password yang baru, maka sistem akan memunculkan pesan : Gambar 4. 101 Messagebox Password Baru dan Konfirmasi Password beda

202 Apabila user sudah benar dalam menginput password-nya, maka sistem akan memunculkan pesan Password Berhasil Diubah. Gambar 4. 102 Messagebox Password Berhasil Diubah 4.4.6.4 User Interface Form Master Karyawan Gambar 4. 103 User Interface Form Master Karyawan Form Master Karyawan dibuat oleh Manajer Umum dan digunakan untuk mengetahui identitas karyawan yang menggunakan sistem. Ketika Form Master Karyawan dibuka, user dapat melihat data karyawan yang telah tersimpan di database pada list table. Untuk melihat detail dari data karyawan, maka user dapat melakukan pencarian dengan menginput Kode Karyawan. Setelah itu, data karyawan tersebut akan tersaji pada list table dan di dalam field-field yang tersedia. User dapat menambah data karyawan baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Kode Karyawan, kemudian user dapat langsung menginput data karyawan, yaitu Nama, memilih

203 Jenis Kelamin, Tanggal Lahir, Alamat, No Telepon, Email, memilih Jabatan, Bagian, dan Gaji ke dalam field yang tersedia. Ketika user memilih Operasional pada atribut Bagian, sistem akan secara otomatis men-generate Shift dan Upah Per Jam. Sedangkan jika ingin mengubah data karyawan, maka user harus memilih data karyawan yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data karyawan tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data karyawan tersebut baru dapat diubah oleh user. Kemudian, setelah selesai menambahkan atau mengubah data karyawan di dalam list table, maka user dapat menekan tombol Simpan untik mengakhirinya dan menampilkan data karyawan yang baru atau yang telah diubah ke dalam list table atau menekan tombol Batal untuk membatalkan penggunaan Form Master Karyawan dan kembali ke Menu Utama. 4.4.6.5 User Interface Form Master Rumah Gambar 4. 104 User Interface Form Master Rumah Form Master Rumah dibuat oleh Arsitek dan digunakan untuk mengetahui unit rumah yang akan dibangun dan dijual oleh perusahaan beserta spesifikasi teknis dari unit rumah tersebut. Ketika Form Master Rumah dibuka, user dapat melihat data rumah yang telah tersimpan di database pada list table. Untuk melihat detail dari

204 data rumah, maka user dapat melakukan pencarian dengan menginput Nomor Rumah. Setelah itu, data rumah tersebut akan tersaji di dalam list table dan tampil pada field-field yang tersedia. User dapat menambah data rumah yang akan dibangun dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Nomor Rumah, kemudian user dapat langsung menginput data rumah, yaitu Tipe, Harga Jual, memilih Status Pembangunan, dan Status Ketersediaan. Ketika tombol Tambah Spesifikasi Teknis di tekan, sistem akan secara otomatis men-generate Nomor Spesifikasi pada Tabel Detail Spesifikasi, kemudian user dapat langsung menginput data spesifikasi unit rumah pada tabel tersebut. Sedangkan jika ingin mengubah data rumah, maka user harus memilih data rumah yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data rumah tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data rumah tersebut baru dapat diubah oleh user. Kemudian, setelah selesai menambahkan atau mengubah data rumah di dalam list table, maka user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data rumah yang baru atau yang telah diubah ke dalam list table atau menekan tombol Batal untuk membatalkan penggunaan Form Master Rumah dan kembali ke Menu Utama.

205 4.4.6.6 User Interface Form Master Pelanggan Gambar 4. 105 User Interface Form Master Pelanggan Form Master Pelanggan dibuat oleh Bagian Marketing dan digunakan untuk mengetahui identitas pelanggan yang melakukan pemesanan unit rumah. Ketika Form Master Pelanggan dibuka, maka user dapat melihat data pelanggan yang telah tersimpan di database pada list table. Untuk melihat detail dari data pelanggan, maka user dapat melakukan pencarian dengan menginput Kode Pelanggan. Setelah itu, data pelanggan tersebut akan tersaji di dalam list table dan tampil pada field-field yang tersedia. User dapat menambah data pelanggan yang baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Kode Pelanggan, kemudian user dapat langsung menginput data pelanggan, yaitu Nama, menginput No KTP, NPWP, memilih Jenis Kelamin, menginput Alamat, No Telepon, dan Email ke dalam field yang tersedia. Sedangkan jika ingin mengubah data pelanggan, maka user harus memilih data pelanggan yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data pelanggan tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data pelanggan tersebut baru dapat diubah oleh user. Kemudian, setelah selesai menambahkan atau mengubah data pelanggan, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data

206 pelanggan yang baru atau yang telah diubah ke dalam list table atau menekan tombol Batal untuk membatalkan penggunaan Form Master Pelanggan dan kembali ke Menu Utama. 4.4.6.7 User Interface Form Master Bank Gambar 4. 106 User Interface Form Master Bank Form Master Bank dibuat oleh Bagian Keuangan dan digunakan untuk mengetahui identitas Bank ketika menerima pembayaran dari pelanggan. Ketika Form Master Bank dibuka, user dapat melihat data bank yang telah tersimpan di database pada list table. Untuk melihat detail dari data bank, maka user dapat melakukan pencarian dengan menginput Kode Bank. Setelah itu, data bank tersebut akan tersaji di dalam list table dan tampil pada field-field yang tersedia. User dapat menambah data bank baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Kode Bank, kemudian user dapat langsung memasukkan data bank, yaitu Nama Bank. Sedangkan jika ingin mengubah data bank, maka user harus memilih data bank yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data bank tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data bank tersebut baru dapat diubah oleh user. Kemudian, setelah selesai menambahkan atau mengubah data bank, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data bank

207 yang baru atau yang telah diubah ke dalam list table atau menekan tombol Batal untuk membatalkan penggunaan Form Master Bank dan kembali ke Menu Utama. 4.4.6.8 User Interface Form Surat Perintah Mulai Bangun Gambar 4. 107 User Interface Form Surat Perintah Mulai Bangun Form Surat Perintah Mulai Bangun (SPMB) dibuat oleh Manajer Umum dan digunakan sebagai dasar untuk memulai pembangunan unit rumah dan diserahkan ke Bagian Keuangan. Ketika Form Surat Perintah Mulai Bangun dibuka, user dapat melihat data SPMB yang telah tersimpan di database pada list table. Untuk melihat detail dari data SPMB, maka user dapat melakukan pencarian dengan menginput Nomor SPMB. Setelah itu, data SPMB tersebut akan tersaji di dalam list table dan tampil pada field-field yang tersedia. User dapat menambah data SPMB baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Nomor SPMB, kemudian user dapat langsung menginput data SPMB, yaitu Tanggal SPMB, Tanggal Mulai, Estimasi Selesai, dan Lama Pelaksanaan ke dalam field yang tersedia. Kemudian, user dapat memilih unit-unit rumah yang akan dibangun dengan memilih Nomor Rumah untuk ditampilkan ke dalam Tabel Detail Rumah. Setelah memilih Nomor Rumah, maka sisten akan menampilkan Nomor Spesifikasi dan Tipe dari rumah tersebut, kemudian user dapat menekan tombol Tambah Rumah untuk

208 menambah dan menampilkan data rumah yang dipilih ke dalam list table rumah. Sedangkan untuk menghapus unit rumah dari list table rumah, maka user harus terlebih dahulu memilih data rumah yang ingin dihapus dari list table rumah, dan kemudian menekan tombol Hapus Rumah. Sedangkan jika ingin mengubah data SPMB, maka user harus memilih data SPMB yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data SPMB tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data SPMB tersebut baru dapat diubah oleh user. Selain itu, user dapat menghapus data SPMB dengan terlebih dahulu memilih data SPMB yang ingin dihapus di list table. Setelah data dipilih, maka user dapat menekan tombol Hapus dan sistem akan menghapus data SPMB tersebut dari list table. Kemudian, setelah selesai menambahkan, mengubah, atau menghapus data SPMB, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data SPMB yang baru atau yang telah diubah ke dalam list table atau menekan tombol Cetak untuk mencetaknya atau menekan tombol Batal untuk membatalkan penggunaan Form Surat Perintah Mulai Bangun dan kembali ke Menu Utama. Gambar 4. 108 Rancangan Formulir Surat Perintah Mulai Bangun

209 4.4.6.9 User Interface Form Surat Perintah Kerja Gambar 4. 109 User Interface Form Surat Perintah Kerja Form Surat Perintah Kerja (SPK) dibuat oleh Bagian Keuangan dan digunakan sebagai dasar untuk melakukan pekerjaaan pembangunan, yang ditujukan untuk Bagian Pengawas Lapangan dan Bagian Pelaksana. Ketika Form SPK dibuka, user dapat melihat data SPK yang telah tersimpan di database pada list table. Untuk melihat detail dari data SPK, maka user dapat melakukan pencarian dengan menginput Nomor SPK. Setelah itu, data SPK tersebut akan tersaji di dalam list table dan tampil pada field-field yang tersedia. User dapat menambah data SPK baru dengan menekan tombol Tambah dan langsung menginput data SPK, yaitu Tanggal SPK, memilih Nomor SPMB, menginput Volume Pekerjaan, dan Harga Borongan ke dalam field yang tersedia. Ketika Nomor SPMB dipilih, maka akan muncul Tanggal SPMB dan data-data rumah di dalam Tabel Detail Rumah. Sedangkan jika ingin mengubah data SPK, maka user harus memilih data SPK yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data SPK tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data SPK tersebut baru dapat diubah oleh user. Selain itu, user dapat menghapus data SPK dengan terlebih dahulu memilih data SPK yang ingin dihapus di list table. Setelah data dipilih, maka user dapat

210 menekan tombol Hapus dan sistem akan menghapus data SPK tersebut dari list table. Kemudian, setelah selesai menambahkan, mengubah, atau menghapus data SPK, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data SPK yang baru atau yang telah diubah ke dalam list table atau menekan tombol Cetak untuk mencetaknya atau menekan tombol Batal untuk membatalkan penggunaan Form Surat Perintah Kerja dan kembali ke Menu Utama. Gambar 4. 110 Rancangan Formulir Surat Perintah Kerja

211 4.4.6.10 User Interface Form Berita Acara Serah Terima Gambar 4. 111 User Interface Form Berita Acara Serah Terima Form Berita Acara Serah Terima (BAST) dibuat oleh Bagian Pelaksana dan digunakan untuk menginformasikan kepada Bagian Pengawas Lapangan bahwa pembangunan unit rumah telah selesai. Ketika Form BAST dibuka, user dapat melihat data BAST yang telah tersimpan di database pada list table. Untuk melihat detail dari data BAST, maka user dapat melakukan pencarian dengan menginput Nomor BAST. Setelah itu, data BAST tersebut akan tersaji di dalam list table dan tampil pada field-field yang tersedia. User dapat menambah data BAST baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Nomor BAST, kemudian user dapat langsung menginput data BAST, yaitu Tanggal BAST, memilih Nomor SPK, dan menginput Keterangan ke dalam field yang tersedia. Ketika Nomor SPK dipilih, maka akan muncul Tanggal SPK dan data SPMB yang merupakan dasar dari pembuatan SPK di dalam Tabel Detail SPMB. Sedangkan jika ingin mengubah data BAST, maka user harus memilih data BAST yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data BAST tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data BAST tersebut baru dapat diubah oleh user. Selain itu, user dapat menghapus data BAST dengan terlebih dahulu memilih data BAST yang ingin dihapus di list table. Setelah data dipilih, maka user dapat

212 menekan tombol Hapus dan sistem akan menghapus data BAST tersebut dari list table. Kemudian, setelah selesai menambahkan, mengubah, atau menghapus data BAST, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data BAST yang baru atau yang telah diubah ke dalam list table atau menekan tombol Cetak untuk mencetaknya atau menekan tombol Batal untuk membatalkan penggunaan Form BAST dan kembali ke Menu Utama. Gambar 4. 112 Rancangan Formulir Berita Acara Serah Terima

213 4.4.6.11 User Interface Form Surat Pemesanan Rumah Gambar 4. 113 User Interface Form Surat Pemesanan Rumah Form Surat Pemesanan Rumah (SPR) dibuat oleh Bagian Marketing dan digunakan untuk mengetahui pesanan pelanggan terhadap unit rumah. Ketika Form SPR dibuka, user dapat melihat data SPR yang telah tersimpan di database pada list table. Untuk melihat detail dari data SPR, maka user dapat melakukan pencarian dengan menginput Nomor SPR. Setelah itu, data SPR tersebut akan tersaji di dalam list table dan tampil pada field-field yang tersedia. User dapat menambah data SPR baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Nomor SPR, kemudian user dapat langsung menginput data SPR, yaitu Tanggal SPR, memilih Kode Pelanggan, memilih Nomor Rumah, memilih Metode Pembayaran, dan menginput Nominal Booking Fee. Ketika Kode Pelanggan dipilih, maka akan muncul nama dan alamat pelanggan tersebut. Kemudian, ketika Nomor Rumah dipilih, maka akan muncul data rumah yang telah dipilih di dalam Tabel Detail Rumah. Pada form SPR, harga jual dapat di input kembali secara manual apabila terdapat perbedaan dengan harga jual unit rumah yang tersimpan di dalam database rumah, yang dapat terjadi apabila adanya kegiatan promosi, adanya potongan harga, dan sebagainya. Harga jual pada form SPR hanya dapat di input oleh Manajer Umum, sehingga pada saat Bagian Marketing menginput data pada form SPR,

214 Bagian Marketing akan memanggil Manajer Umum untuk melakukan penginputan harga jual pada form SPR secara langsung. Sedangkan jika ingin mengubah data SPR, maka user harus memilih data SPR yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data SPR tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data SPR tersebut baru dapat diubah oleh user. Selain itu, user dapat menghapus data SPR dengan terlebih dahulu memilih data SPR yang ingin dihapus di list table. Setelah data dipilih, maka user dapat menekan tombol Hapus dan sistem akan menghapus data SPR tersebut dari list table. Kemudian, setelah selesai menambahkan, mengubah, atau menghapus data SPR, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data SPR yang baru atau yang telah diubah ke dalam list table atau menekan tombol Cetak untuk mencetaknya atau menekan tombol Batal untuk membatalkan penggunaan Form Surat Pemesanan Rumah dan kembali ke Menu Utama. Pada saat Bagian Marketing menekan tombol Simpan, maka sistem secara otomatis akan mengubah status ketersediaan rumah menjadi Tidak Tersedia di data rumah. Gambar 4. 114 Rancangan Formulir Surat Pemesanan Rumah

215 4.4.6.12 User Interface Form Pembayaran Tanda Jadi Gambar 4. 115 User Interface Form Pembayaran Tanda Jadi Form Pembayaran Tanda Jadi (PTJ) dibuat oleh Bagian Marketing dan digunakan untuk mencatat pembayaran tanda jadi (booking fee) atas unit rumah yang telah dipesan oleh pelanggan. Ketika Form PTJ dibuka, user dapat melihat data PTJ yang telah tersimpan di database pada list table. Untuk melihat detail dari data PTJ, maka user dapat melakukan pencarian dengan menginput Nomor PTJ. Setelah itu, data PTJ tersebut akan tersaji ke dalam field-field yang tersedia. User dapat menambah data PTJ baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Nomor PTJ, kemudian user dapat langsung menginput data PTJ yang baru, yaitu Tanggal PTJ, memilih Nomor SPR, memilih Jenis Penerimaan, memilih Kode Bank, menginput Nomor Rekening dan Nama Rekening ke dalam field yang tersedia. Ketika Kode Bank dipilih, maka akan muncul Nama Bank. Kemudian, ketika Nomor SPR dipilih, maka akan muncul data SPR yang telah dipilih di dalam Tabel Detail SPR. Sedangkan jika ingin mengubah data PTJ, maka user harus memilih data PTJ yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data PTJ tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data PTJ tersebut baru dapat diubah oleh user.

216 Selain itu, user dapat menghapus data PTJ dengan terlebih dahulu memilih data PTJ yang ingin dihapus di list table. Setelah data dipilih, maka user dapat menekan tombol Hapus dan sistem akan menghapus data PTJ tersebut dari list table. Kemudian, setelah selesai menambahkan, mengubah, atau menghapus data PTJ, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data PTJ yang baru atau yang telah diubah ke dalam list table atau menekan tombol Batal untuk membatalkan penggunaan Form PTJ dan kembali ke Menu Utama. Pada saat Bagian Marketing menekan tombol Simpan, maka sistem secara otomatis mencatat jurnal penerimaan uang tanda jadi, yaitu : Cash (D) Unearned Booking Fee Revenue (K) xxxxx xxxxx 4.4.6.13 User Interface Form Pembayaran Rumah Gambar 4. 116 User Interface Form Pembayaran Rumah Form Pembayaran Rumah (PR) dibuat oleh Bagian Keuangan dan digunakan setelah menerima pembayaran atas unit rumah secara tunai dari pelanggan. Ketika Form PR dibuka, user dapat melihat data PR yang telah tersimpan di database pada list table. Untuk melihat detail dari data PR, maka user dapat melakukan pencarian

217 dengan menginput Nomor PR. Setelah itu, data PR tersebut akan tersaji di dalam list table dan tampil pada field-field yang tersedia. User dapat menambah data PR baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Nomor PR, kemudian user dapat langsung menginput data PR yang baru, yaitu Tanggal PR, memilih Nomor SPR, memilih Jenis Penerimaan, memilih Kode Bank, menginput No Bukti, No Rekening, dan Nama Rekening ke dalam field yang tersedia. Ketika Kode Bank dipilih, maka akan muncul Nama Bank. Kemudian, ketika Nomor SPR dipilih, maka akan muncul data SPR yang dipilih di dalam Tabel Detail SPR. Sedangkan jika ingin mengubah data PR, maka user harus memilih data PR yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data PR tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data PR tersebut baru dapat diubah oleh user. Selain itu, user dapat menghapus data PR dengan terlebih dahulu memilih data PR yang ingin dihapus di list table. Setelah data dipilih, maka user dapat menekan tombol Hapus dan sistem akan menghapus data Pembayaran Rumah tersebut dari list table. Kemudian, setelah selesai menambahkan, mengubah, atau menghapus data PR, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data PR yang baru atau yang telah diubah ke dalam list table atau menekan tombol Batal untuk membatalkan penggunaan Form Pembayaran Rumah dan kembali ke Menu Utama. Pada saat Bagian Keuangan menekan tombol Simpan, sistem secara otomatis mencatat jurnal penerimaan kas dan realisasi dari pendapatan booking fee, yaitu : Cash (D) xxxxx Sales Revenue (K) xxxxx PPN Keluaran (K) xxxxx BPHTB (K) xxxxx BBN (K) xxxxx

218 Unearned Booking Fee Revenue (D) xxxxx Booking Fee Revenue (K) xxxxx Keterangan : PPN Keluaran = 10% * Harga Jual BPHTB = 5% * (Harga Jual - NPOPTKP) BBN = 2% * Harga Jual 4.4.6.14 User Interface Form KPR Gambar 4. 117 User Interface Form KPR Form KPR dibuat oleh Bagian Keuangan dan digunakan untuk menginput pembayaran DP yang telah diterima dari pelanggan untuk penjualan unit rumah melalui KPR Bank. Ketika Form KPR dibuka, user dapat melihat data KPR yang telah tersimpan di database pada list table. Untuk melihat detail dari data KPR, maka user dapat melakukan pencarian dengan menginput Nomor KPR. Setelah itu, data KPR tersebut akan tersaji di dalam list table dan tampil pada field-field yang tersedia.

219 User dapat menambah data KPR baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Nomor KPR, kemudian user dapat langsung menginput Tanggal KPR, memilih Nomor SPR, memilih Status Pembayaran DP, memilih Jenis Penerimaan, memilih Kode Bank, menginput No Bukti, Nomor Rekening, dan Nama Rekening ke dalam field yang tersedia. Ketika Kode Bank dipilih, maka akan muncul Nama Bank. Kemudin, ketika Nomor SPR dipilih, maka akan muncul data SPR yang telah dipilih di dalam Tabel Detail SPR. Sedangkan jika ingin mengubah data KPR, maka user harus memilih data KPR yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data KPR tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data KPR tersebut baru dapat diubah oleh user. Selain itu, user dapat menghapus data KPR dengan terlebih dahulu memilih data KPR yang ingin dihapus di list table. Setelah data dipilih, maka user dapat menekan tombol Hapus dan sistem akan menghapus data KPR tersebut dari list table. Kemudian, setelah selesai menambahkan, mengubah, atau menghapus data KPR, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data KPR yang baru ke dalam list table atau menekan tombol Cetak untuk mencetaknya atau menekan tombol Batal untuk membatalkan penggunaan Form KPR dan kembali ke Menu Utama. Ketika Bagian Keuangan menekan tombol Simpan, sistem secara otomatis akan mencatat jurnal realisasi dari pendapatan booking fee, yaitu : Unearned Booking Fee Revenue (D) xxxxx Booking Fee Revenue (K) xxxxx

220 Gambar 4. 118 Rancangan Formulir KPR 4.4.6.15 User Interface Form Pembayaran Cicilan KPR Gambar 4. 119 User Interface Form Pembayaran Cicilan KPR Form Pembayaran Cicilan KPR (PCK) dibuat oleh Bagian Keuangan dan digunakan untuk menginput pembayaran cicilan KPR pelanggan berdasarkan bukti pembayaran kredit yang diterima dari Bank. Ketika Form PCK dibuka, user dapat melihat data PCK yang telah tersimpan di database pada list table. Untuk melihat

221 detail dari data PCK, maka user dapat melakukan pencarian dengan menginput Nomor PCK. Setelah itu, data PCK tersebut akan tersaji di dalam list table dan tampil pada field-field yang tersedia. User dapat menambah data PCK baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Nomor PCK, kemudian user dapat langsung memilih Nomor KPR. Ketika Nomor KPR dipilih, maka akan muncul Tanggal KPR. Detail Pembayaran berisi Tanggal dan Nominal Pembayaran yang dapat di input secara langsung. User dapat memasukkan pembayaran cicilan KPR pertama dengan menginput Tanggal Pembayaran dan Nominal Pembayaran ke dalam field yang tersedia. Untuk menambah dan menampilkan data pembayaran tersebut ke dalam list table pembayaran, user dapat menekan tombol Tambah Pembayaran. Setiap bulannya, Bagian Keuangan akan menerima bukti pembayaran cicilan KPR pelanggan dari Bank. Untuk menginput pembayaran cicilan KPR tersebut, Bagian Keuangan akan memilih data PCK yang ingin di update pada list table. Jika data sudah dipilih, maka data PCK tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data PCK tersebut baru dapat diubah oleh user. Untuk menambah pembayaran, user dapat langsung menginput Tanggal dan Nominal Pembayaran pada Detail Pembayaran dan menekan tombol Tambah Pembayaran. Data pembayaran yang baru akan secara otomatis muncul di dalam list table pembayaran. Selain itu, user dapat menghapus data PCK dengan terlebih dahulu memilih data PCK yang ingin dihapus di list table. Setelah data dipilih, maka user dapat menekan tombol Hapus dan sistem akan menghapus data PCK tersebut dari list table. Kemudian, setelah selesai menambahkan, mengubah, atau menghapus data PCK, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data PCK yang baru atau yang telah diubah ke dalam list table atau menekan tombol Batal untuk membatalkan penggunaan Form Pembayaran Cicilan KPR dan kembali ke Menu Utama.

222 4.4.6.16 User Interface Form Surat Perjanjian Jual Beli Gambar 4. 120 User Interface Form Surat Perjanjian Jual Beli Form Surat Perjanjian Jual Beli (SPJB) dibuat oleh Bagian Keuangan setelah kredit in-house pelanggan disetujuui dan digunakan sebagai bukti kesepakatan kredit antara pelanggan dengan perusahaan. Ketika Form SPJB dibuka, user dapat melihat data SPJB yang telah tersimpan di database pada list table. Untuk melihat detail dari data SPJB, maka user dapat melakukan pencarian dengan menginput Nomor SPJB. Setelah itu, data SPJB tersebut akan tersaji di dalam list table dan tampil pada fieldfield yang tersedia. User dapat menambah data SPJB baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Nomor SPJB, kemudian user dapat langsung menginput Tanggal SPJB, memilih Nomor SPR, dan memilih Kode Pelanggan ke dalam field yang tersedia. Ketika Nomor SPR dipilih, maka akan muncul data pelanggan pada kolom pihak kedua dan data SPR yang telah dipilih di dalam Tabel Detail SPR. Sedangkan jika ingin mengubah data SPJB, maka user harus memilih data SPJB yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data SPJB tersebut akan tersaji ke dalam field-field yang tersedia namun masih

223 belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data SPJB tersebut baru dapat diubah oleh user. Selain itu, user dapat menghapus data SPJB dengan terlebih dahulu memilih data SPJB yang ingin dihapus di list table. Setelah data dipilih, maka user dapat menekan tombol Hapus dan sistem akan menghapus data SPJB tersebut dari list table. Kemudian, setelah selesai menambahkan, mengubah, atau menghapus data SPJB, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data SPJB yang baru atau yang telah diubah ke dalam list table atau menekan tombol Cetak untuk mencetaknya atau menekan tombol Batal untuk membatalkan penggunaan Form SPJB dan kembali ke Menu Utama. Ketika Bagian Keuangan menekan tombol Simpan, sistem secara otomatis akan mencatat jurnal penjualan kredit dan realisasi dari pendapatan booking fee, yaitu : Account Receivable (D) Sales Revenue (K) PPN Keluaran (K) xxxxx xxxxx xxxxx BPHTB (K) xxxxx BBN (K) xxxxx Unearned Booking Fee Revenue (D) xxxxx Booking Fee Revenue (K) xxxxx Keterangan : PPN Keluaran = 10% * Harga Jual BPHTB = 5% * (Harga Jual - NPOPTKP) BBN = 2% * Harga Jual

224 Gambar 4. 121 Rancangan Formulir Surat Perjanjian Jual Beli Gambar 4. 122 Rancangan Formulir Surat Perjanjian Jual Beli

225 4.4.6.17 User Interface Form Pembayaran Cicilan Rumah Gambar 4. 123 User Interface Form Pembayaran Cicilan Rumah Form Pembayaran Cicilan Rumah (PCR) dibuat oleh Bagian Keuangan dan digunakan untuk menginput pembayaran cicilan rumah yang diterima dari pelanggan untuk penjualan secara kredit in house. Ketika Form PCR dibuka, user dapat melihat data PCR yang telah tersimpan di database pada list table. Untuk melihat detail dari data PCR, maka user dapat melakukan pencarian dengan menginput Nomor PCR. Setelah itu, data PCR tersebut akan tersaji di dalam list table dan tampil pada field-field yang tersedia. User dapat menambah data PCR baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Nomor PCR, kemudian user dapat langsung memilih Status PCR menjadi Open dan memilih Nomor SPJB. Ketika Nomor SPJB dipilih, sistem akan secara otomatis men-generate Harga Jual. Pada saat melakukan penambahan data PCR, Bagian Keuangan akan menginput tanggal Jatuh Tempo untuk pembayaran 1 dan Nominal Cicilan 1. Setelah itu, sistem akan secara otomatis men-generate Jatuh Tempo dan Nominal Cicilan untuk pembayaran 2,3, dan 4. Setiap menerima pembayaran cicilan rumah dari pelanggan, Bagian Keuangan akan mengubah data PCR yang sudah ada, yaitu dengan cara memilih data PCR pada list table. Jika data sudah dipilih, maka data PCR tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah

226 menekan tombol Ubah, maka data PCR tersebut baru dapat diubah oleh user. Kemudian, sesuai dengan tangggal Jatuh Tempo-nya, Bagian Keuangan akan mengubah Status Pembayaran menjadi Lunas, memilih Jenis Penerimaan, memilih Kode Bank, menginput No Bukti, No Rekening, dan Nama Bank pada field yang tersedia. Pada pembayaran terakhir, user akan mengubah Status PCR menjadi Closed untuk menandakan bahwa pembayaran cicilan rumah sudah lunas secara keseluruhan. Selain itu, user dapat menghapus data PCR dengan terlebih dahulu memilih data PCR yang ingin dihapus di list table. Setelah data dipilih, maka user dapat menekan tombol Hapus dan sistem akan menghapus data PCR tersebut dari list table. Kemudian, setelah selesai menambahkan, mengubah, atau menghapus data Faktur Penagihan, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data PCR yang baru atau yang telah diubah ke dalam list table atau menekan tombol Batal untuk membatalkan penggunaan Form Pembayaran Cicilan Rumah dan kembali ke Menu Utama. Pada saat Bagian Keuangan menekan tombol Simpan, sistem secara otomatis akan mencatat jurnal penerimaan kas, yaitu : Cash (D) Account Receivable (K) xxxxxx xxxxx Setiap 14 hari (2 minggu) sebelum tanggal Jatuh Tempo, sistem akan memberikan notifikasi bahwa piutang pelanggan akan jatuh tempo dengan menampilkan messagebox sebagai berikut : Gambar 4. 124 Messagebox Notifikasi Piutang Pelanggan yang Akan Jatuh Tempo

227 4.4.6.18 User Interface Form Faktur Penagihan Gambar 4. 125 User Interface Form Faktur Penagihan Form Faktur Penagihan dibuat oleh Bagian Keuangan sebagai dasar untuk melakukan penagihan cicilan unit rumah kepada pelanggan untuk penjualan secara kredit in-house. Ketika Form Faktur Penagihan dibuka, user dapat melihat data Faktur Penagihan yang telah tersimpan di database pada list table. Untuk melihat detail dari data Faktur Penagihan, maka user dapat melakukan pencarian dengan menginput Nomor Faktur Penagihan. Setelah itu, data Faktur Penagihan tersebut akan tersaji di dalam list table dan tampil pada field-field yang tersedia. User dapat menambah data Faktur Penagihan baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Nomor Faktur Penagihan, kemudian user dapat langsung menginput Tanggal Penagihan, menginput Nomor Cicilan, dan memilih Nomor PCR. Ketika Nomor PCR dipilih, maka akan muncul data PCR yang telah dipilih di dalam Tabel Detail PCR. Sedangkan jika ingin mengubah data Faktur Penagihan, maka user harus memilih data Faktur Penagihan yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data Faktur Penagihan tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data Faktur Penagihan tersebut baru dapat diubah oleh user. Selain itu, user dapat menghapus data Faktur Penagihan dengan terlebih dahulu memilih data Faktur Penagihan yang ingin dihapus di list table. Setelah data

228 dipilih, maka user dapat menekan tombol Hapus dan sistem akan menghapus data Faktur Penagihan tersebut dari list table. Kemudian, setelah selesai menambahkan, mengubah, atau menghapus data Faktur Penagihan, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data Faktur Penagihan yang baru atau yang telah diubah ke dalam list table atau menekan tombol Cetak untuk mencetaknya atau menekan tombol Batal untuk membatalkan penggunaan Form Faktur Penagihan dan kembali ke Menu Utama. Gambar 4. 126 Rancangan Formulir Faktur Penagihan

229 4.4.6.19 User Interface Form Progress Kerja Mingguan Gambar 4. 127 User Interface Form Progress Kerja Mingguan Form Progress Kerja Mingguan (PKM) dibuat oleh Bagian Pengawas Lapangan dan digunakan untuk menginformasikan progress kegiatan pembangunan unit rumah kepada Manajer Umum setiap minggunya. Ketika Form PKM dibuka, user dapat melihat data PKM yang telah tersimpan di database pada list table. Untuk melihat detail dari data PKM, maka user dapat melakukan pencarian berdasarkan atribut yang diinginkan dan menginput kata kunci dari atribut tersebut. Setelah itu, data PKM tersebut akan tersaji ke dalam field-field yang tersedia. User dapat menambah data PKM yang baru dengan menekan tombol Tambah dan sistem akan secara otomatis men-generate Nomor PKM, kemudian user dapat langsung menginput Periode Awal, Periode Akhir, memilih Nomor SPK, dan menginput Progress Kerja. Ketika Nomor SPK dipilih, maka akan muncul data SPK yang telah dipilih di dalam Tabel Detail SPK. Sedangkan jika ingin mengubah data PKM, maka user harus memilih data PKM yang ingin diubah di dalam list table terlebih dahulu. Jika data sudah dipilih, maka data PKM tersebut akan tersaji ke dalam field-field yang tersedia namun masih belum dapat diubah (disable). Setelah menekan tombol Ubah, maka data PKM tersebut baru dapat diubah oleh user. Selain itu, user dapat menghapus data PKM dengan terlebih dahulu memilih data PKM yang ingin dihapus di list table. Setelah data dipilih, maka user dapat

230 menekan tombol Hapus dan sistem akan menghapus data PKM tersebut dari list table. Kemudian, setelah selesai menambahkan, mengubah, atau menghapus data PKM, user dapat menekan tombol Simpan untuk mengakhirinya dan menampilkan data PKM yang baru atau yang telah diubah ke dalam list table atau menekan tombol Cetak untuk mencetaknya atau menekan tombol Batal untuk membatalkan penggunaan Form Progress Kerja Mingguan dan kembali ke Menu Utama. Gambar 4. 128 Rancangan Formulir Progress Kerja Mingguan 4.4.6.20 User Interface Form Laporan Hasil Kerja Gambar 4. 129 User Interface Form Laporan Hasil Kerja

231 Form Laporan Hasil Kerja digunakan untuk membuat laporan terkait dengan kegiatan pembangunan unit rumah yang telah selesai dikerjakan. Bagian Pengawas Lapangan dapat memilih periode awal dan periode akhir dari Laporan Hasil Kerja. Sistem akan menampilkan Progress Kerja Mingguan yang ada selama periode yang dipilih. Bagian Pengawas Lapangan dapat menekan tombol Cetak untuk mencetak Laporan Hasil Kerja atau menekan tombol Batal untuk membatalkan penggunaan Form Laporan Hasil Kerja dan kembali ke Menu Utama. Gambar 4. 130 Rancangan Laporan Hasil Kerja 4.4.6.21 User Interface Form Laporan Pemesanan Rumah Gambar 4. 131 User Interface Form Laporan Pemesanan Rumah

232 Form Laporan Pemesanan Rumah digunakan untuk membuat laporan terkait dengan kegiatan pemesanan unit rumah oleh pelanggan setiap bulannya. Bagian Marketing dapat memilih periode awal dan periode akhir dari Laporan Pemesanan Rumah. Sistem akan menampilkan Surat Pemesanan Rumah yang ada selama periode yang dipilih. Bagian Marketing dapat menekan tombol Cetak untuk mencetak Laporan Pemesanan Rumah atau menekan tombol Batal untuk membatalkan penggunaan Form Laporan Pemesanan Rumah dan kembali ke Menu Utama. Gambar 4. 132 Rancangan Laporan Pemesanan Rumah 4.4.6.22 User Interface Form Laporan Piutang Gambar 4. 133 User Interface Form Laporan Piutang

233 Form Laporan Piutang digunakan untuk membuat laporan terkait dengan piutang usaha yang timbul dari kegiatan penjualan unit rumah setiap bulannya. Bagian Akuntansi dapat memilih periode awal dan periode akhir dari Laporan Piutang. Sistem akan menampilkan Faktur Penagihan yang ada selama periode yang dipilih. Bagian Akuntansi dapat menekan tombol Cetak untuk mencetak Laporan Piutang atau menekan tombol Batal untuk membatalkan penggunaan Form Laporan Piutang dan kembali ke Menu Utama. Gambar 4. 134 Rancangan Laporan Piutang

234 4.4.6.23 User Interface Form Laporan Penerimaan Kas Gambar 4. 135 User Interface Form Laporan Penerimaan Kas Form Laporan Penerimaan Kas digunakan untuk membuat laporan terkait dengan penerimaan kas yang berasal dari pembayaran tanda jadi (Booking Fee), penjualan unit rumah secara tunai, dan pembayaran cicilan rumah setiap bulannya. Bagian Akuntansi dapat memilih periode awal dan periode akhir daril Laporan Penerimaan Kas. Setelah itu, Bagian Akuntansi dapat : 1. Menekan tombol Pembayaran Tanda Jadi untuk mencetak Laporan Penerimaan Kas dari pembayaran tanda jadi 2. Menekan tombol Pembayaran Rumah untuk mencetak Laporan Penerimaan Kas dari pembayaran unit rumah untuk penjualan tunai. 3. Menekan tombol Pembayaran Cicilan Rumah untuk mencetak Laporan Penerimaan Kas dari pembayaran cicilan rumah untuk penjualan secara kredit in house. Sistem akan menampilkan data-data yang ada selama periode yang dipilih. Bagian Akuntansi dapat menekan tombol Cetak untuk mencetak Laporan Penerimaan Kas atau menekan tombol Batal untuk membatalkan penggunaan Form Laporan Penerimaan Kas dan kembali ke Menu Utama.

235 Gambar 4. 136 Rancangan Laporan Penerimaan Kas per Pembayaran Tanda Jadi Gambar 4. 137 Rancangan Laporan Penerimaan Kas per Pembayaran Rumah

236 Gambar 4. 138 Rancangan Laporan Penerimaan Kas per Pembayaran Cicilan Rumah 4.4.6.24 User Interface Form Laporan Jurnal Gambar 4. 139 User Interface Form Laporan Jurnal Form Laporan Jurnal digunakan untuk membuat laporan terkait dengan transaksi akuntansi yang timbul dari kegiatan penjualan unit rumah setiap bulannya. Bagian Akuntansi dapat memilih periode awal dan periode akhir dari Laporan Jurnal.

237 Sistem akan menampilkan data Jurnal yang ada selama periode yang dipilih. Bagian Akuntansi dapat menekan tombol Cetak untuk mencetak Laporan Jurnal atau menekan tombol Batal untuk membatalkan penggunaan Form Laporan Jurnal dan kembali ke Menu Utama. Gambar 4. 140 Rancangan Laporan Jurnal

238 4.4.7 Persistent Object 1. Persistent Object Class Karyawan Entity : Karyawan Primary Key : Kode_Karyawan Foreign Key : - Tabel 4. 26 Kamus Data Class Karyawan Attribute Data_Type Length Description Kode_Karyawan Char 5 Kode Karyawan autogenerated yang dimulai dari satu dan berurut Nama_Karyawan Varchar 100 Nama karyawan Jenis_Kelamin Varchar 10 Tanggal_Lahir Datetime - Jenis kelamin karyawan Tanggal lahir karyawan Alamat Varchar 250 Alamat karyawan No_Telepon Varchar 20 Nomor telepon karyawan Email Varchar 100 Email karyawan Password Varchar 20 Password Karyawan Jabatan Varchar 20 Jabatan karyawan Bagian Varchar 20 Bagian karyawan Shift Varchar 20 Shift kerja karyawan untuk Bagian Operasional Gaji Float - Gaji karyawan Upah_Per_Jam Float - Upah per jam untuk karyawan Bagian Operasional Tabel 4. 27 Persistent Object Class Karyawan Kode_ Karyawan Nama_Karyawan Jenis_ Kelamin Tanggal_ Lahir Alamat No_Telep on K-001 Wawan Setiawan L 05/07/1964 Jl. Asoka no 9 5493093 K-002 Listiani Maghfiroh P 03/07/1988 Jl. Mawar no 20 4874257 K-003 Mario Jerzy L 23/10/1985 Jl. Melati no 5 2495893

239 K-004 Diannur Dama L 16/05/1979 Jl. Anggrek no 18 7902375 K-005 Yusnimar Sahan P 12/06/1962 Jl. Lily no 104 5923803 Email Password Jabatan Bagian Shift Gaji wsetiawan@g mail.com listiani@yahoo.com Mario@gmail. com diannur@gmai l.com yusni@yahoo. com w1234 Manajer Umum Manajer Umum Upah_ Per_Jam - 6.500.000 - l0307 Staff Marketing - 2.500.000-231091 Staff 1605dd yusni62 Staff Kepala Bagian Operasion al Operasion al 09.00-17.00-10.000 09.00-17.00-10.000 Keuangan - 5.000.000-2. Persistent Object Class Rumah Entity : Rumah Primary Key : No_Rumah Foreign Key : - Tabel 4. 28 Kamus Data Class Rumah Attribute Data_Type Length Description No_Rumah Char 6 Nomor Rumah autogenerated yang dimulai dari satu dan berurut Tipe Varchar 10 Tipe rumah Harga_Jual Float - Harga jual rumah Status_ Pembangunan Status_ Ketersediaan Varchar 20 Varchar 20 Status pembangunan rumah Status ketersediaan rumah Tabel 4. 29 Persistent Object Class Rumah No_Rumah Tipe R-0001 36/108 R-0002 36/108 Status_ Pembangunan Selesai Dibangun Selesai Dibangun Status_ Ketersediaan Harga_Jual Tidak Tersedia 115.000.000 Tidak Tersedia 115.000.000

240 R-0003 36/108 R-0004 36/108 R-0005 36/108 R-0006 36/108 Belum Dibangun Belum Dibangun Belum Dibangum Belum Dibangun Tersedia 110.000.000 Tersedia 110.000.000 Tersedia 105.000.000 Tersedia 105.000.000 3. Persistent Object Class Spesifikasi Teknis Entity : Spesifikasi Teknis Primary Key : No_Spesifikasi Foreign Key : No_Rumah Tabel 4. 30 Kamus Data Class Spesifikasi Teknis Attribute Data_Type Length Description No_Spesifikasi Char 6 Nomor Spesifikasi Teknis autogenerated yang dimulai dari satu dan berurut No_Rumah Char 6 Nomor Rumah Pondasi Varchar 250 Spesifikasi pondasi rumah Dinding Varchar 250 Spesifikasi dinding rumah Lantai Varchar 250 Spesifikasi lantai rumah Penutup_Atap Varchar 250 Spesifikasi penutup atap rumah Pintu Varchar 250 Spesifikasi pintu rumah Kusen Varchar 250 Spesifikasi kusen rumah Jendela Varchar 250 Spesifikasi jendela rumah Plafon Varchar 250 Spesifikasi plafon rumah Sanitary Varchar 250 Spesifikasi sanitary rumah Air Varchar 250 Spesifikasi air rumah Daya_Listrik Varchar 250 Spesifikasi daya listrik rumah Carport Varchar 250 Spesifikasi garasi rumah

241 Tabel 4. 31 Persistent Object Class Spesifikasi Teknis No_ Spesifikasi No_ Rumah ST-001 R-01 ST-002 R-02 ST-003 R-03 Pondasi Dinding Lantai Batu Kali/Gunung Batu Kali/Gunung Batu Kali/Gunung Bata Press, Finishing Plester, Aci, dan Cat (Exterior Mowilex/S etara, Interior Catilax) Bata Press, Finishing Plester, Aci, dan Cat (Exterior & Interior Kemtone/S etara) Bata Press, Finishing Plester, Aci, dan Cat (Exterior Kemtone, Interior Spectrum) Keramik 30x30 Keramik 60x60 Keramik 40x40 Penutup_ Atap Multiroof Genteng Beton Multiroof Pintu Panil Kayu Bayam Panil Kayu Meranti Panil Kayu Kamper Banjar Kusen Jendela Plafon Sanitary Air Daya_Listrik Carport Kayu Bayam/ Sejenisn ya Kotak Kayu Bayam + Kaca 5mm Gypsum Kloset Duduk TOTO Sumur Bor 900, 1300 VA/220 Volt Rabat Beton Kayu Meranti/ Sejenisn ya Kotak Kayu Meranti + Kaca 5mm Gypsum Kloset Duduk TOTO Sumur Bor 900,1300 VA/220 Volt Rabat Beton Kayu Kamper Banjat Kotak Kayu Kamper Banjar + Kaca 5mm Triplek dicat Kloset Jongkok Sumur Bor 900, 1300 VA/220 Volt Rabat Beton

242 4. Persistent Object Class Pelanggan Entity : Pelanggan Primary Key : Kode_Pelanggan Foreign Key : - Tabel 4. 32 Kamus Data Class Pelanggan Attribute Data_Type Length Description Kode_Pelanggan Char 7 Kode Pelanggan autogenerated yang dimulai dari satu dan berurut Nama_Pelanggan Varchar 100 Nama pelanggan No_KTP Varchar 20 NPWP Varchar 20 Jenis_Kelamin Varchar 10 Nomor Kartu Tanda Penduduk pelanggan Nomor Pokok Wajib Pajak pelanggan Jenis kelamin pelanggan Alamat Varchar 250 Alamat pelanggan No_Telepon Vachar 20 Nomor Telepon pelanggan Email Varchar 100 Email pelanggan Kode_ Pelanggan Tabel 4. 33 Persistent Object Class Pelanggan Nama_Pelanggan No_KTP NPWP PL-0001 Iswandi 1603142708740001 09.254.294.3-407.000 PL-0002 Nini Priyanti 3276014710830012 31.288.332.5-412.000 PL-0003 Bagus Yudi 3275021040660013 03.026.562.3-805.000 PL-0004 Hersanto 3171026300873003 07.861.795.8-605.000 PL-0005 Sugiono 3127044121365003 23.345.867.8-705.000 PL-0006 Susi 1603031470660012 01.867.987.8-105.000 Jenis_ Kelamin Alamat No_Telepon Email L Naman Regency B5 8329568 Is1D@yahoo.com P Jl. Tambak II 2960504 priyantinini@gmail.com L Perum Purwodadi B2 8769540 bagusyu@hotmail.com L Jl. Meranti no 89B 4285493 Hersanto@telkom.com

243 L Jl. Flamboyan no 47 5950349 sugiono@yahoo.com P Jl. Kharisma no 3 2235590 susi@gmail.com 5. Persistent Object Class Bank Entity : Bank Primary Key : Kode_Bank Foreign Key : - Tabel 4. 34 Kamus Data Class Bank Attribute Data_Type Length Description Kode_Bank Char 6 Kode Bank autogenerated yang dimulai dari satu dan berurut Nama_Bank Varchar 100 Nama Bank Tabel 4. 35 Persistent Object Class Bank Kode_Bank BK-001 BK-002 BK-003 BK-004 Nama_Bank Bank BCA Bank Mandiri Bank Permata Bank CIMB Niaga 6. Persistent Object Class Surat Perintah Mulai Bangun Entity : Surat Perintah Mulai Bangun Primary Key : No_SPMB Foreign Key : No_Rumah, Kode_Karyawan Tabel 4. 36 Kamus Data Class Surat Perintah Mulai Bangun Attribute Data_Type Length Description No_SPMB Char 8 Tanggal_SPMB Datetime - Nomor Surat Perintah Mulai Bangun autogenerated yang dimulai dari satu dan berurut Tanggal pembuatan Surat Perintah

244 No_Rumah Char 6 Tanggal_Mulai Datetime - Estimasi_Selesai Datetime - Lama_Pelaksanaan Varchar 20 Mulai Bangun Nomor Rumah yang akan dibangun Tanggal mulai pembangunan Estimasi tanggal selesai pembangunan Lama pelaksanaan pembangunan Kode_Karyawan Char 5 Kode Karyawan Tabel 4. 37 Persistent Object Class Surat Perintah Mulai Bangun No_SPMB Tanggal_ SPMB No_ Rumah Tanggal_ Mulai Estimasi_ Selesai Lama_ Pelaksanaan Kode_ Karyawan SPMB-001 29/03/2010 R-0001 05/03/2010 05/01/2011 10 Bulan K-001 SPMB-002 01/04/2012 R-0002 08/04/2012 08/12/2012 8 Bulan K-001 SPMB-003 26/01/2014 R-0003 02/02/2014 02/08/2014 6 Bulan K-001 7. Persistent Object Class Surat Perintah Kerja Entity : Surat Perintah Kerja Primary Key Foreign Key : No_SPK : No_SPMB, Kode_Karyawan Tabel 4. 38 Kamus Data Class Surat Perintah Kerja Attribute Data_Type Length Description No_SPK Char 7 Tanggal_SPK Datetime - No_SPMB Char 8 Volume_Pekerjaan Varchar 50 Harga_Borongan Float - Nomor Surat Perintah Kerja autogenerated yang dimulai dari satu dan berurut Tanggal pembuatan Surat Perintah Kerja Nomor Surat Perintah Mulai Bangun Total seluruh volume pekerjaan pembangunan Total seluruh harga borongan pembangunan

245 Kode_Karyawan Char 5 Kode Karyawan Tabel 4. 39 Persistent Object Class Surat Perintah Kerja No_SPK Tanggal_SPK No_SPMB Volume_ Harga_ Kode_ Pekerjaan Borongan Karyawan SPK-001 29/03/2010 SPMB-001 115.000 m3 9.200.000.000 K-005 SPK-002 01/04/2012 SPMB-002 110.000 m3 8.800.000.000 K-005 SPK-003 26/01/2014 SPMB-003 107.000 m3 8.560.000.000 K-005 8. Persistent Object Class Berita Acara Serah Terima Entity : Berita Acara Serah Terima Primary Key : No_BAST Foreign Key : No_SPK, Kode_Karyawan Tabel 4. 40 Kamus Data Class Berita Acara Serah Terima Attribute Data_Type Length Description No_BAST Char 8 Tanggal_BAST Datetime - No_SPK Char 7 Keterangan Varchar 250 Nomor Berita Acara Serah Terima autogenerated yang dimulai dari satu dan berurut Tanggal pembuatan Berita Acara Serah Terima Nomor Surat Perintah Kerja Keterangan Berita Acara Serah Terima Kode_Karyawan Char 5 Kode Karyawan Tabel 4. 41 Persistent Object Class Berita Acara Serah Terima No_BAST Tanggal_BAST No_SPK Keterangan Kode_Karyawan BAST-001 05/01/2011 SPK-001 BAST-002 08/12/2012 SPK-002 BAST-003 02/08./2014 SPK-003 Telah dibangun 126 unit rumah Telah dibangun 118 unit rumah Telah dibangun 113 unit rumah K-004 K-004 K-004

246 9. Persistent Object Class Surat Pemesanan Rumah Entity : Surat Pemesanan Rumah Primary Key : No_SPR Foreign Key : Kode_Pelanggan, No_Rumah Tabel 4. 42 Kamus Data Class Surat Pemesanan Rumah Attribute Data_Type Length Description No_SPR Char 8 Tanggal_SPR Datetime - Nomor Surat Pemesanan Rumah autogenerated yang dimulai dari satu dan berurut Tanggal pembuatan Surat Pemesanan Rumah Kode_Pelanggan Char 7 Kode Pelanggan No_Rumah Char 6 Nomor Rumah yang dipesan Harga_Jual Float - Harga Jual rumah Metode_ Pembayaran Nominal_Booking _Fee Varchar 20 Float - Metode Pembayaran rumah Nominal pembayaran uang tanda jadi atas pemesanan rumah Kode_Karyawan Char 5 Kode Karyawan Tabel 4. 43 Persistent Object Class Surat Pemesanan Rumah No_SPR Tanggal_SPR Kode_Pelanggan No_Rumah Harga_Jual SPR-0001 29/01/2014 PL-0001 R-0006 105.000.000 SPR-0002 08/02/2014 PL-0002 R-0005 105.000.000 SPR-0003 12/02/2014 PL-0003 R-0004 110.000.000 SPR-0004 03/03/2014 PL-0004 R-0003 110.000.000 SPR-0005 07/03/2014 PL-0005 R-0002 115.000.000 SPR-0006 11/03/2014 PL-0006 R-0001 115.000.000 Metode_Pembayaran Nominal_Booking_Fee Kode_Karyawan Tunai 1.000.000 K-002 Tunai 1.000.000 K-002 KPR 1.000.000 K-002 KPR 1.000.000 K-002

247 Kredit In House 1.000.000 K-002 Kredit In House 1.000.000 K-002 10. Persistent Object Class Pembayaran Tanda Jadi Entity : Pembayaran Tanda Jadi Primary Key : No_PTJ Foreign Key : No_SPR, Kode_Bank, Kode_Karyawan Tabel 4. 44 Kamus Data Class Pembayaran Tanda Jadi Attribute Data_Type Length Description No_PTJ Char 8 Tanggal_PTJ Datetime - No_SPR Char 8 Nominal_Booking _Fee Jenis_Penerimaan Varchar 10 Nomor Pembayaran Tanda Jadi autogenerated yang dimulai dari satu dan berurut Tanggal pembuatan Pembayaran Tanda Jadi Nomor Surat Pemesanan Rumah Float - Nominal tanda jadi Jenis penerimaan pembayaran, tunai atau transfer Kode_Bank Char 6 Kode Bank No_Bukti Varchar 50 Nomor Bukti Setor atau Bukti Transfer No_Rekening Varchar 50 Nomor Rekening Nama_Rekening Varchar 100 Nama Rekening Kode_Karyawan Char 5 Kode Karyawan Tabel 4. 45 Persistent Object Class Pembayaran Tanda Jadi No_PTJ Tanggal_PTJ No_SPR Nominal_ Jenis_ Booking_Fee Penerimaan Kode_Bank PTJ-0001 29/01/2014 SPR-0001 1.000.000 Tunai BK-001 PTJ-0002 08/02/2014 SPR-0002 1.000.000 Transfer BK-002 PTJ-0003 12/02/2014 SPR-0003 1.000.000 Tunai BK-003 PTJ-0004 03/03/2014 SPR-0004 1.000.000 Transfer BK-004 PTJ-0005 07/03/2014 SPR-0005 1.000.000 Transfer BK-001 PTJ-0006 11/03/2014 SPR-0006 1.000.000 Tunai BK-002

248 No_Bukti No_ Nama_ Kode_ Rekening Rekening Karyawan 6008-088 1651979710 Iswandi K-002 S1AD1A39-7738 0060004168856 Nini Priyanti K-002 7686 4107496438 Bagus Yudi K-002 7275-0010 5170105621113 Hersanto K-002 2450-456 4980701285 Sugiono K-002 S1AD1C0S- 5124 1420067877778 Susi K-002 11. Persistent Object Class Pembayaran Rumah Entity : Pembayaran Rumah Primary Key : No_PR Foreign Key : No_SPR, Kode_Bank, Kode_Karyawan Tabel 4. 46 Kamus Data Class Pembayaran Rumah Attribute Data_Type Length Description No_PR Char 7 Tanggal_PR Datetime - No_SPR Char 8 Harga_Jual Float - Jenis_Penerimaan Varchar 10 Nomor Pembayaran Rumah autogenerated yang dimulai dari satu dan beurut Tanggal pembuatan Pembayaran Rumah Nomor Surat Pemesanan Rumah Harga jual unit rumah Jenis penerimaan pembayaran, tunai atau transfer Kode_Bank Char 6 Kode Bank No_Bukti Varchar 50 Nomor Bukti Setor atau Bukti Transfer No_Rekening Varchar 50 Nomor Rekening Nama_Rekening Varchar 100 Nama Rekening Kode_Karyawan Char 5 Kode Karyawan

249 Tabel 4. 47 Persistent Object Class Pembayaran Rumah No_PR Tanggal_PR No_SPR Harga_Jual Jenis_Penerimaan Kode_Bank 09/03/2014 16/04/2014 PR- 0001 PR- 0002 SPR- 0001 SPR- 0002 105.000.000 Transfer BK-001 105.00.000 Transfer BK-002 No_Bukti No_Rekening Nama_Rekening Kode_Karyawan 6008-088 1651979710 Iswandi K-005 S1AD1A39-7738 0060004168856 Nini Priyanti K-005 12. Persistent Object Class KPR Entity : KPR Primary Key :No_KPR Foreign Key :No_SPR, Kode_Bank, Kode_Karyawan Tabel 4. 48 Kamus Data Class KPR Attribute Data_Type Length Description No_KPR Char 8 Nomor KPR autogenerated yang dimulai dari satu dan berurut Tanggal_KPR Datetime - Tanggal pembuatan KPR No_SPR Char 8 Nomor Surat Pemesanan Rumah Nominal_DP Float - Nominal DP yang dibayar Status_Pembayaran Status pembayaran Varchar 20 _DP DP Jenis penerimaan Jenis_Penerimaan Varchar 10 pembayaran DP, tunai atau transfer Kode_Bank Char 6 Kode Bank No_Bukti Varchar 50 Nomor Bukti No_Rekening Varchar 50 Nomor Rekening Nama_Rekening Varchar 100 Nama Rekening Kode_Karyawan Char 5 Kode Karyawan

250 Tabel 4. 49 Persistent Object Class KPR No_KPR Tanggal_KPR No_SPR Nominal_DP 20/02/2014 11/03/2014 KPR- 0001 KPR- 0002 SPR- 0003 SPR- 0004 Status_ Pembayaran_DP Jenis_ Penerimaan 22.000.000 BK-001 Transfer 22.000.000 BK-002 Transfer Kode_Bank No_Bukti No_ Rekening Nama_ Rekening Kode_ Karyawan BK-004 7686 4107496438 Bagus Yudi K-005 BK-001 7275-0010 5170105621113 Hersanto K-005 13. Persistent Object Class Pembayaran Cicilan KPR Entity : Pembayaran Cicilan KPR Primary Key : No_PCK Foreign Key : No_KPR, Kode_Karyawan Tabel 4. 50 Kamus Data Class Pembayaran Cicilan KPR Attribute Data_Type Length Description No_PCK Char 8 Nomor Pembayaran Cicilan KPR autogenerated yang dimulai dari satu dan berurut No_KPR Char 8 Nomor KPR Tanggal_ Pembayaran Nominal_ Pembayaran Datetime - Float - Tanggal pembayaran cicilan KPR Nominal pembayaran cicilan KPR Kode_Karyawan Char 5 Kode Karyawan No_PCK Tabel 4. 51 Persistent Object Class Pembayaran Cicilan KPR No_KPR Tanggal_ Pembayaran Nominal_ Pembayaran Kode_ Karyawan PCR-0001 KPR-0001 27/02/2014 1.800.000 K-005 PCR-0002 KPR-0002 18/03/2014 1.800.000 K-005

251 14. Persistent Object Class Surat Perjanjian Jual Beli Entity : Surat Perjanjian Jual Beli Primary Key : No_SPJB Foreign Key :No_SPR, Kode_Pelanggan, Kode_Karyawan Tabel 4. 52 Kamus Data Class Surat Perjanjian Jual Beli Attribute Data_Type Length Description No_SPJB Char 9 Tanggal_SPJB Datetime - No_SPR Char 8 Harga_Jual Float - Nomor Surat Perjanjian Jual Beli autogenerated yang dimulai dari satu dan berurut Tanggal pembuatan Surat Perjanjian Jual Beli Nomor Surat Pemesanan Rumah Harga jual unit rumah Kode_Pelanggan Char 7 Kode Pelanggan Kode_Karyawan Char 5 Kode Karyawan Tabel 4. 53 Persistent Object Class Surat Perjanjian Jual Beli No_SPJB Tanggal_ Harga_ Kode_ Kode_ No_SPR SPJB Jual Pelanggan Karyawan SPJB-0001 08/03/2014 SPR-0005 115.000.000 PL-0005 K-005 SPJB-0002 12/03/2014 SPR-0006 115.000.000 PL-0006 K-005 15. Persistent Object Class Pembayaran Cicilan Rumah Entity : Pembayaran Cicilan Rumah Primary Key : No_PCR Foreign Key : No_SPJB, Kode_Bank, Kode_Karyawan Tabel 4. 54 Kamus Data Class Pembayaran Cicilan Rumah Attribute Data_Type Length Description No_PCR Char 8 Nomor Pembayaran Cicilan Rumah autogenerated

252 Status_PCR Varchar 10 No_SPJB Char 9 Harga_Jual Float - Jatuh_Tempo Datetime - Nominal_Cicilan Float - Status_Pembayaran Varchar 20 Jenis_Penerimaan Varchar 10 yang dimulai dari satu dan berurut Status Pembayaran Cicilan Rumah Nomor Surat Perjanjian Jual Beli Harga jual unit rumah Tanggal jatuh tempo pembayaran cicilan Nominal pembayaran cicilan Status pembayaran cicilan Jenis penerimaan pembayaran cicilan Kode_Bank Char 6 Kode Bank No_Bukti Varchar 50 Nomor Bukti No_Rekening Varchar 50 Nomor Rekening Nama_Rekening Varchar 100 Nama Rekening Kode_Karyawan Char 5 Kode Karyawan Tabel 4. 55 Persistent Object Class Pembayaran Cicilan Rumah No_PCR Status_ PCR No_SPJB Harga_ Jual Jatuh_ Tempo Nominal_ Cicilan Status_ Pembayaran PCR-0001 Open SPJB-0001 115.000.000 15/03/2014 46.000.000 Lunas PCR-0002 Closed SPJB-0002 115.000.000 12/12/2014 23.000.000 Lunas Jenis_ Penerimaan Kode_ Bank No_Bukti No_ Rekening Nama_ Rekening Kode_ Karyawan Transfer BK-001 2990-123 4980701285 Sugiono K-005 Transfer BK-002 G1AF1C0D-6732 1420067877778 Susi K-005

253 16. Persistent Object Class Faktur Penagihan Entity : Faktur Penagihan Primary Key : No_FakturPenagihan Foreing Key : No_PCR, Kode_Karyawan Tabel 4. 56 Kamus Data Class Faktur Penagihan Attribute Data_Type Length Description No_FakturPenagihan Char 7 Tanggal_Penagihan Datetime - No_PCR Char 8 Nomor Faktur Penagihan autogenerated yang dimulai dari satu dan berurut Tanggal penagihan cicilan Nomor Pembayaran Cicilan Rumah No_Cicilan Integer - Nomor Cicilan Nominal_Cicilan Float - Nominal pembayaran cicilan Kode_Karyawan Char 5 Kode Karyawan Tabel 4. 57 Persistent Object Class Faktur Penagihan No_ FakturPenagihan Tanggal_ Penagihan No_PCR No_Cicilan Nominal_ Cicilan Kode_ Karyawan PG-0001 09/03/2014 PCR-0001 1 46.000.000 K-005 PG-0008 12/06/2014 PCR-0002 4 23.000.000 K-005 17. Persistent Object Class Progress Kerja Mingguan Entity : Progress Kerja Mingguan Primary Key : No_PKM Foreign Key : No_SPK, Kode_Karyawan Tabel 4. 58 Kamus Data Class Progress Kerja Mingguan Attribute Data_Type Length Description No_PKM Char 8 Nomor Progress Kerja Mingguan autogenerated

254 Periode_Awal Datetime - Periode_Akhir Datetime - No_SPK Char 7 Progress_Kerja Varchar 250 yang dimulai dari satu dan berurut Tanggal awal Progress Kerja Mingguan Tanggal akhir Progress Kerja Mingguan Nomor Surat Perintah Kerja Progress kerja selama seminggu Kode_Karyawan Char 5 Kode Karyawan Tabel 4. 59 Persistent Object Class Progress Kerja Mingguan No_PKM Periode_ Awal Periode_ Akhir No_SPK Progress_Kerja Kode_ Karyawan PKM-0001 26/01/2014 02/02/2014 SPK-003 PKM-0002 03/02/2014 10/02/2014 SPK-003 PKM-0003 11/02/2014 18/02/2014 SPK-003 PKM-0004 19/02/2014 26/02/2014 SPK-003 Tahap pengerjaan 5% Tahap pengerjaan 10% Tahap pengerjaan 15% Tahap pengerjaan 20% K-003 K-003 K-003 K-003 18. Persistent Object Class Chart of Account Entity : Chart of Account Primary Key : Kode_COA Foreign Key : - Tabel 4. 60 Kamus Data Class Chart of Account Attribute Data_Type Length Description Kode_COA Char 10 Kode Chart of Account Nama_Akun Varchar 50 Nama Akun

255 Tabel 4. 61 Persistent Object Class Chart of Account Kode_COA Nama_Akun 101 Cash 106 Account Receivable 203 Unearned Revenue 204 PPN Keluaran 205 Bea Perolehan Hak atas Tanah dan Bangunan 206 Bea Balik Nama 401 Sales Revenue 19. Persistent Object Class Jurnal Entity : Jurnal Primary Key : Kode_Jurnal Foreign Key : No_PTJ, No_PR, No_SPJB, No_PCR Tabel 4. 62 Kamus Data Class Jurnal Attribute Data_Type Length Description Kode_Jurnal Char 6 Kode Jurnal autogenerated yang dimulai dari satu dan berurut Tanggal_Jurnal Datetime - Tanggal jurnal No_PTJ Char 8 No_PR Char 7 No_SPJB Char 9 No_PCR Char 8 Nomor Pembayaran Tanda Jadi Nomor Pembayaran Rumah Nomor Surat Perjanjian Jual Beli Nomor Pembayaran Cicilan Rumah Tabel 4. 63 Persistent Object Class Jurnal Kode_Jurnal Tanggal_Jurnal No_PTJ No_PR J-0001 31/03/2104 PTJ -0004 - J-0002 31/03/2014 - PR-0001 J-0003 31/03/2014 - PR-0001 J-0004 31/03/2014 - - J-0005 31/03/2014 - - J-0006 31/03/2104 - -

256 J-0007 31/03/2014 - - No_SPJB No_PCR - - - - - - SPJB-0001 - SPJB-0001 - - PCR-0001 - PCR-0001 20. Persistent Object Class Detail Jurnal Entity Primary Key : Detail Jurnal : Kode_Jurnal, Kode_COA Foreign Key : - Tabel 4. 64 Kamus Data Class Detail Jurnal Attribute Data_Type Length Description Kode_Jurnal Char 6 Kode Jurnal Kode_COA Char 10 Kode Chart of Account Status Varchar 10 Status jurnal Nominal Float - Nominal Tabel 4. 65 Persistent Object Class Detail Jurnal Kode_COA Kode_Jurnal Status Nominal 101 J-0001 Debit 1.000.000 203 J-0001 Kredit 1.000.000 203 J-0002 Debit 105.000.000 401 J-0002 Kredit 90.150.000 204 J-0002 Kredit 10.500.000 205 J-0002 Kredit 2.250.000 206 J-0002 Kredit 2.100.000

257 203 J-0003 Debit 1.000.000 401 J-0003 Kredit 1.000.000 106 J-0004 Debit 115.000.000 401 J-0004 Kredit 98.450.000 204 J-0004 Kredit 11.500.000 205 J-0004 Kredit 2.750.000 206 J-0004 Kredit 2.300.000 203 J-0005 Debit 1.000.000 401 J-0005 Kredit 1.000.000

258 4.5 Design Activities and Environment 4.5.1 Deployment Environment Deployment Environment yang digunakan adalah Multitier Architecture karena sistem akan digunakan oleh user yang berasal dari bagian yang berbeda-beda di dalam perusahaan. Setiap user akan menggunakan komputer yang berbeda-beda, namun dengan model dan manufaktur yang sama, yang akan membentuk suatu sistem komputer tunggal yang besar, sehingga tipe Multitier Architecture yang cocok untuk digunakan oleh perusahaan adalah Clustered Architecture. Sedangkan deployment architecture yang digunakan adalah Centralized Architecture dikarenakan semua sumber komputer terletak pada satu lokasi yang sama, yang dapat memproses aplikasi yang bersifat batch maupun real-time. Gambar 4. 141 Clustered Architecture Sumber : Satzinger et al. (2005: 271) 4.5.2 Software Architecture Software Architecture yang digunakan adalah Two-tier Achitecture, dimana terdapat View Layer yang memungkinkan user untuk dapat berinteraksi dengan sistem melalui User Interface. Kemudian, untuk dapat melakukan kegiatan transaksi, user dapat mengkses, mengambil, dan menyimpan data yang terdapat di dalam database melalui Data Layer. Gambar 4. 142 Two-tier Architecture Sumber: Satzinger et al. (2005: 280)