BAB III ANALISA DAN PERANCANGAN SISTEM

Transkripsi

1 BAB III ANALISA DAN PERANCANGAN SISTEM Pada bab ini akan dibahas tahap-tahap dalam analisa dan perancangan sistem aplikasi SMS Gateway ini, yaitu analisa proses sistem dan alur informasi pesan, perancangan database, interface dan layanan sistem. Proses perancangan aplikasi SMS Gateway dua arah ini, berbasis web dengan pemrograman PHP dengan memanfaatkan Gammu sebagai library tools yang memuat perintah pengiriman sms dan juga yang menjadi jembatan penghubung modem (device) dengan aplikasi SMS Gateway. 3.1 ANALISA PROSES SISTEM APLIKASI Proses aplikasi pertama kali dimulai dengan registrasi klien Narada Prima Cosulting untuk mendapatkan ID ( Nomor Identitas ) dalam mengakses informasi dari SMS Gateway, contohnya sebagai berikut : NPC1 = PT. Sukses Selalu NPC2 = PT. ABC Nomor ID ini yang nantinya dipakai untuk proses pengaksesan informasi seperti proses jumlah bayar pajak dengan mengetik NPC1 berarti aplikasi membaca informasi yang diakses adalah untuk PT. Sukses Selalu, hal ini penting untuk menyeragamkan pengkodean nama klien, jika yang dipakai nama perusahaan bisa saja yang dimasukan berupa SS (singkatan), Sukses, Sukses selalu, dan Suksel. Banyaknya kemungkinan yang bisa dimasukan oleh klien sebagai ID untuk proses pengaksesan informasi, sehingga perlunya pengkodean ID dengan dimulai dengan NPC ( Narada Prima Consulting). Dengan registrasi ini diharapkan pengguna sistem akan lebih terkontrol, sehingga sistem akan tahu 25

2 26 bilamana sms yang masuk memakai ID NPC berarti merupakan klien yang sudah terdaftar dalam database aplikasi SMS Gateway ini. NPC A B Sms Gateway C D E KLIEN Gambar 3.1 Proses kerja sistem Penjelasan Proses Proses yang terjadi dalam Aplikasi SMS Gateway : 1. A : NPC mengisi data-data yang diperlukan dalam database seperti nomor handphone, pesan notifikasi, data perpajakan yang diakses klien, serta No Id klien melalui form aplikasi input data. 2. B : NPC mengecek informasi dari database SMS Gateway tentang status pembayaran pajak klien apakah sudah dibayar atau belum. 3. C : Klien Mengirimkan SMS untuk Registrasi 4. D : Klien Mengirimkan SMS untuk request informasi, status bayar. 5. E : SMS Gateway memberikan Informasi berupa SMS/Pesan. Proses-proses diatas adalah proses yang terjadi dalam aplikasi SMS Gateway ini, dimana NPC sebagai penyedia layanan memberikan data-data perpajakan yang dapat diakses oleh klien melalui aplikasi tersebut, lalu klien akan melakukan pembayaran pajak di bank, setelah itu klien akan memberikan update status bayar ke aplikasi melalui pesan. Admin akan melakukan cek data, bagi setiap klien yang sudah memberikan status bayar, jika klien sudah melakukan pembayaran maka akan diteruskan dengan pelaporan pajak. Untuk itu akan dijelaskan pada sub bab selanjutnya tentang aliran informasi dari tahap proses awal sampai dengan akhir dari setiap kliennya. Bagaimana aliran pesan ini berjalan?

3 Tahap proses aliran informasi (pesan) Pada penjelasan sebelumnya sudah dijelaskan tentang proses-proses yang terjadi pada aplikasi SMS Gateway ini, dimana terdiri dari beberapa proses yang dilakukan oleh NPC sebagai penyedia layanan aplikasi dan Klien sebagai pemakai layanan aplikasi. Tahap-tahap aliran pesan dan informasi ini adalah sebagai berikut : 1. Admin (user/staff) akan memasukan data-data perpajakan yang nantinya akan diakses oleh klien. 2. Klien akan melakukan registrasi NO ID, untuk mendapatkan ID yang nantinya dipakai sebagai ID dalam melakukan pengaksesan data pada aplikasi ini. 3. Sistem autoreply akan diaktifkan oleh admin, setiap saatnya untuk melakukan proses pesan. Dalam layanan ini, pesan akan diolah sedemikian rupa dan diterjemahkan kedalam beberapa permintaan, lalu sistem akan memberikan pesan balasan sesuai permintaan yang diminta. 4. Klien yang sudah mendapatkan jumlah bayar pajaknya, akan melakukan pembayaran pajak dibank, kantor pos maupun tempat-tempat yang ditentukan untuk melakukan pembayaran ini. 5. Setiap klien yang sudah melakukan pembayaran, akan memberikan informasi kepada NPC melalui pesan kepada sistem bahwa status bayar pajak sudah dilakukan. Disini terjadi update status bayar pajak klien dari yang secara default BELUM menjadi SUDAH. 6. Admin akan melalukan cek data status bayar dari tabel pajak. Untuk setiap status bayar yang sudah dilakukan akan dilaporkan pajaknya di Kantor Pelayanan Pajak (KPP). 7. Jika pelaporan berhasil, maka staff NPC akan memberitahukan Admin untuk meng-update status lapor pajak dari BELUM menjadi SUDAH. 8. Klien akan melakukan permintaan status lapor ini melalui pesan, dan sistem akan memberikan pesan balasan dari layanan autoreply. Jika pajak sudah dilapor maka proses informasi ini berakhir disini.

4 28 Setiap klien di NPC, akan melakukan kedelapan proses yang sama setiap bulannya dalam menyelesaikan pelaporan pajak. Aliran informasi pesan seperti yang telah dijabarkan diatas akan berlangsung berulang-ulang setiap bulan dan dilakukan oleh semua klien yang ada pada NPC. Akhir dari proses ini adalah klien mendapatkan informasi status lapor pajak yang sudah berhasil, karena dalam proses informasi dua arah ini, tujuannya adalah melakukan proses pelaporan perpajakan mulai dari akses jumlah pajak, update status bayar sampai dengan akses status lapor, disinilah proses berakhir UML (Unified Modeling Language) Unified modeling Languange (UML) adalah sebuah bahasa yang berdasarkan grafik/gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan software berbasis OO (Object-Oriented). UML sendiri juga memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan komponen-komponen yang diperlukan dalam sistem software. Dalam pemodelan ini, biasanya digunakan pemodelan dalam bentuk diagram atau gambar seperti use case diagram, activity diagram, sequence diagram, class diagram, dan lain sebagainya. Tergantung dari kebutuhan dan kompleksitas sistem. Pemodelan Dalam UML adalah sebagai berikut : 1. Skenario adalah serangkain langkah-langkah yang menjabarkan sebuah interaksi antara seseorang pengguna dengan sebuah sistem. 2. Use case diagram merupakan salah satu diagram untuk memodelkan aspek prilaku sistem. Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Use case diagram adalah interaksi antara aktor eksternal dan sistem, hasil yang dapat diamati oleh aktor, berorientasi pada tujuan, di deskripsikan pada diagram use case dan teks. Diagram use case melibatkan : - Sistem : Sesuatu yang kita bangun

5 29 - Aktor : Segala sesuatu yang berinteraksi dengan sistem - Relasi : Hubungan sistem dengan aktor Use Case Diagram SMS Gateway NPC SMS GATEWAY NPC Meminta ID Mengelola Data Admin (staff) include Mengakses Data Informasi Pajak include Klien include Gambar 3.2 Use case aplikasi sms gateway Penjelasan Use Case Aplikasi SMS Gateway NPC : a. Proses registrasi : - Klien mengirimkan pesan registrasi - Admin akan mengecek ketersediaan No ID pada tabel ID Klien. - Admin akan mengirimkan ID yang tersedia melalui aplikasi. b. Proses olah data data : - Admin akan melakukan tambah, ubah dan hapus data dari data-data yang terdapat dalam aplikasi ini sesuai dengan kebutuhannya. c. Proses akses data :

6 30 - Klien hanya dapat mengakses data dan melakukan update status bayar dengan mengirimkan sms dengan format yang telah ditentukan. 3. Activity Diagram : merupakan diagram yang menunjukan alur aktivitas yang ada pada sistem mulai dari awal sampai dengan proses berakhir, keputusan yang mungkin terjadi dan bagaimana proses akan berakhir. Activity diagram proses Registrasi Parsing SMS Cek Bukan registrasi registrasi Akses informasi pajak Cek ketersediaan ID Tentukan ID Kirim ID Gambar 3.3 Activity diagram registrasi Penjelasan Diagram Activity Registrasi : 1. Pada awal proses, klien mengirimkan sms registrasi kedalam sistem. 2. Sistem aplikasi dengan layanan autoreply akan mengecek isi pesan, dan memberikan pesan notifikasi kepada klien. 3. Admin akan mengecek sms/pesan, jika registrasi maka admin akan mengecek ketersediaan NO ID, dan menginput NO ID sesuai dengan Perusahaan yang melakukan registrasi. 4. Nomor ID dikirim oleh admin kepada klien melalui aplikasi.

7 31 Activity Diagram Proses Akses Data User Sistem Aktifkan Autoreply Parsing SMS inbox [format sms salah] [format sms benar] [pph 21] [Id & bulan salah] Notifikasi kesalahan [bukan pph 21] [Id & bulan benar] Proses query Notifikasi kesalahan [ pph 23] [Id & bulan salah] [bukan pph 23] [Id & bulan benar] Proses query Notifikasi kesalahan [request pph 25] [Id & bulan salah] [bukan pph 25] [Id & bulan benar] Proses query Notifikasi kesalahan [update 21] [Id & bulan salah] [not update 21] [Id & bulan benar] Proses query Notifikasi kesalahan Gambar 3.4 Activity diagram akses data

8 32 User Sistem [update 23] [Id & bulan salah] [update 23] [Id & bulan benar] Proses query Notifikasi kesalahan [lapor 21] [Id & bulan salah] [bukan lapor 21] [Id & bulan benar] Proses query Notifikasi kesalahan [lapor 23] [Id & bulan salah] [bukan lapor 23] [Id & bulan benar] Proses query Notifikasi kesalahan [lapor 25] [Id & bulan salah] [bukan lapor 25] [Id & bulan benar] Proses query Notifikasi kesalahan Proses kirim Gambar 3.5 Activity diagram akses data (lanjutan)

9 33 Flowchart : START Parsing SMS inbox IF pesan [format sms salah] [format sms benar] [pph 21] [Id & bulan salah] NOTIFIKASI SALAH IF PPH [bukan pph 21] [Id & bulan benar] PROSES QUERY NOTIFIKASI SALAH IF PPH [ pph 23] [Id & bulan salah] [bukan pph 23] IF PPH [Id & bulan benar] [request pph 25] PROSES QUERY NOTIFIKASI SALAH [Id & bulan salah] [bukan pph 25] [Id & bulan benar] PROSES QUERY NOTIFIKASI SALAH IF update [update 21] [Id & bulan salah] [not update 21] [Id & bulan benar] PROSES QUERY NOTIFIKASI SALAH Gambar 3.6 Flowcahart mengakses data

10 IF update [update 23] [Id & bulan salah] [update 23] [Id & bulan benar] PROSES QUERY NOTIFIKASI SALAH IF lapor [lapor 21] [Id & bulan salah] [bukan lapor 21] [Id & bulan benar] PROSES QUERY NOTIFIKASI SALAH IF lapor [lapor 23] [Id & bulan salah] [bukan lapor 23] [Id & bulan benar] PROSES QUERY NOTIFIKASI SALAH IF lapor [bukan lapor 25] PROSES KIRIM PESAN [lapor 25] [Id & bulan benar] PROSES QUERY [Id & bulan salah] NOTIFIKASI SALAH END Gambar 3.7 Flowchart mengakses data (lanjutan) Penjelasan activity diagram akses data : 1. Admin mengaktifkan layanan autoreply.

11 35 2. Sistem melakukan query, dan mengirimkan pesan permintaan jumlah bayar pajak dari klien. 3. Klien yang sudah mendapatkan jumlah bayar pajak akan melakukan pembayaran pajak di bank atau di kantor pos. 4. Klien yang sudah melakukan pembayaran pajak akan mengirimkan status bayar untuk meng-update status bayar pajak. 5. Sms diterima, layanan autoreply akan mengolah pesan tersebut, lalu query akan meng-update status bayar pajak pada tabel pajak. 6. Admin akan melakukan akses data status bayar pajak, bagi semua klien yang sudah melakukan pembayaran akan dilakukan pelaporan pajak. 7. Semua pelaporan pajak yang sudah dilakukan dan berhasil, akan di-update pada status lapor pajak pada database. 8. Klien yang mengakses status lapor akan menerima status lapor pajak tersebut. Dalam aktivitas akses data ini, adalah proses yang terjadi oleh satu klien dan satu jenis pajak, dalam kenyataannya yang terjadi dalam lingkup pekerjaan banyak akses yang diterima sistem dan satu klien bisa melakukan banyak proses untuk beberapa jenis pajak sehingga disini bisa terjadi banyak proses parallel. 4. Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa pesan yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait). Sequence Diagram Registrasi Klien Inbox Outbox Menu Data Admin Sms registrasi Proses Pesan CEK ID Input ID Terima ID Klien Kirim ID Gambar 3.8 Sequence Diagram Registrasi

12 36 Sequence Diagram Akses Data Pajak Klien Inbox Outbox Menu Data Aktifkan Autoreply Input data Request PPh autoreply Akses Data PPh autoreply Query Pesan Kirim Pesan Update Bayar autoreply Update Status Bayar Query Pesan Kirim Pesan Request lapor autoreply Akses Data Lapor Query Pesan Kirim Pesan Gambar 3.9 Sequence Diagram Akses Data Kebutuhan Sistem Aplikasi SMS Gateway Aplikasi SMS Gateway ini dibuat dengan dasar kebutuhan sistem informasi dalam Narada Prima Consulting dimana ada aliran pesan yang secara rutin dalam

13 37 setiap bulannya dalam proses pembuatan laporan pajak klien. Sehingga diperlukan sistem informasi yang membantu proses aliran pesan dan informasi ini. Dimana klien dapat melakukan akses informasi dan meng-update informasi sehingga dapat mempermudah pekerjaan dalam melakukan pemberitahuan informasi dan pengumpulan data dalam membuat dan melaporkan laporan perpajakan dari setiap klien NPC. Dalam analisa kebutuhan sistem informasi NPC ini, dapat kita jabarkan sebagai berikut : 1. Diperlukan sistem yang dapat melakukan pemberitahuan secara massal untuk pesan-pesan dan hal-hal yang bersifat rutin seperti konfirmasi data pajak, konfirmasi waktu bayar pajak, dan lain sebagainya. 2. Diperlukan sistem yang secara sistematis melakukan rekap data pajak klien seperti jumlah bayar pajak, status bayar, dan status lapor. 3. Diperlukan sistem informasi yang sederhana dan otomatis dalam menjawab setiap permintaan klien yang berhubungan dengan laporan perpajakan seperti halnya pesan singkat atau sms. 4. Diperlukan sistem informasi dua arah yang membantu proses pembuatan sampai dengan pelaporan laporan perpajakan dari setiap klien NPC. Dalam analisa kebutuhan sistem, diperlukan sebuah sistem informasi berbasis SMS Gateway. Karena teknologi sms saat ini sudah sangat memasyarakat dan sangat sederhana. Setiap orang dari berbagai kalangan usia, pendidikan, dan status dapat menggunakan dan memakai teknologi sms di ponsel mereka masingmasing. Sehingga aplikasi SMS Gateway ini sangat cocok menjadi solusi dari kebutuhan akan sistem informasi yang diperlukan. Untuk itu aplikasi ini dibuat dengan melakukan pendekatan dari analisa kebutuhan sistem yang telah disebutkan diatas.

14 PENGOLAHAN INFORMASI PESAN (SMS). Pada tahap ini akan menjelaskan proses pengolahan informasi dari pesan (sms) yang diterima pada aplikasi SMS Gateway, dimana sms akan diolah dan diproses dalam aplikasi untuk melakukan query-query yang direquest oleh klien maupun perintah-perintah layanan aplikasi untuk melakukan pengolahan pesan. Pengolahan pesan ini sampai pada pengiriman balasan sms dari setiap request klien sampai pada akhir proses informasi Penerimaan SMS (Pesan) Masuk. Pada proses ini setiap pesan/sms yang masuk dari klien akan diterima oleh operator gsm (sim card), lalu aplikasi SMS Gateway dengan modul Gammu akan mengambil setiap pesan yang berada di sim card masuk kedalam database, dan ditempatkan dalam table inbox. Di dalam tabel inilah, pesan/sms akan diolah sesuai dengan request dari pesan tersebut, apakah pesan tersebut melakukan registrasi, menanyakan informasi perpajakan atau memberikan informasi tentang status bayar Registrasi Klien Pada tahap ini menjelaskan pengolahan sms untuk pengecekan sms registrasi ID klien, dengan format REG Nama_Perusahaan. Setiap pesan/sms yang masuk dengan awalan REG akan dikategorikan sebagai proses registrasi. Proses registrasi ini berguna untuk memberikan ID kepada klien untuk menggunakan aplikasi ini, agar memudahkan pengecekan identitas saat akses data informasi. Jika penggunaan ID ini tidak diseragamkan maka akan kesulitan dalam kontrol ID pengguna aplikasi saat pengecekan format sms. a. Klien melakukan registrasi No ID dengan mengirimkan sms ke sistem aplikasi dengan menyertakan nama perusahaan. b. User/Admin memberikan No ID kepada klien sesuai dengan urutan No ID yang tersedia dan mengirimnya melalui aplikasi SMS Gateway.

15 Request Informasi Jumlah Bayar Pajak. Pada tahap ini akan menjelaskan proses akses data jumlah pajak (perpajakan) dimana kita kategorikan jenis pajak yang banyak dan umum ada pada perusahaan seperti pph pasal 21, pph pasal 23, dan pph pasal 25. Sms/pesan yang masuk dengan Format INFO ID_klien Jenis_PPH Bulan akan dikategorikan kedalam permintaan (request) informasi pajak. Sistem akan mengirimkan jumlah pajaknya kepada klien melalui sms, sesuai dengan permintaan klien. Sistem akan mengolah pesan menjadi beberapa bagian seperti pada flowchart dibawah ini. Pengolahan memakai algoritma Nested IF untuk membedakan kategori pajak yang satu dengan yang lain Status Bayar dan Status Lapor Pajak Pada layanan ini semua sms dengan format INFO ID_klien Status Bulan akan dikategorikan sebagai sms update status bayar dan format INFO ID_klien Lapor Bulan dikategorikan meminta status lapor. Semua klien yang sudah mengupdate data status bayarnya akan dilaporkan pajaknya beserta dengan bukti bayarnya. Setiap pelaporan yang berhasil akan di update dalam data status lapornya, sedangkan yang belum dilaporkan diberikan keterangan BELUM. Proses ini yang menjadi akhir dari alur proses pesan. Dimana, pelaporan pajak sudah selesai setiap bulannya, dan proses ini akan terus berjalan setiap bulan. Dalam cek status bayar dan lapor ini terdapat dua proses yaitu update bayar dan request status lapor. Ketika status lapor pajak sudah selesai, ini menjadi akhir dari proses pesan. Proses ini akan berulang setiap bulannya, sehingga diperlukan sistem yang sistematis dalam penyampaian informasi ini Pengiriman SMS (Pesan) Keluar Pada proses pengiriman sms dalam aplikasi SMS Gateway ini dibagi menjadi 3 (tiga) kategori pengiriman yaitu sms secara manual/biasa, sms autorelpy, dan sms broadcast (notifikasi). Ketiga kategori tersebut merupakan fitur-fitur yang berguna dalam melakukan pengiriman sms dalam aplikasi ini agar lebih mudah

16 40 dalam penggunaannya dan melakukan pengiriman sms baik secara satu persatu maupun bersamaan (broadcast). 1. Sms manual/biasa Pengiriman sms dengan cara ini adalah mengirim sms seperti yang dilakukan di ponsel/hp, yaitu mengetik isi pesan dan memasukan nomor telepon secara manual. Pengiriman sms ini biasanya dikirim secara satu persatu dan dilakukan secara manual. 2. Sms Autoreply Pengiriman sms ini dilakukan secara otomatis oleh aplikasi sehingga sistem secara otomatis memberikan jawaban atau pesan balasan secara semi otomatis. Biasanya fitur autoreply ini banyak dipakai untuk hal-hal yang bersifat sms terformat. 3. Sms Broadcast Sms broadcast adalah sms yang langsung dikirim kebanyak nomor telepon secara bersamaan. Sms broadcast ini biasa dipakai untuk pemberitahuan atau sebuah notifikasi, banyak yang mengembangkan dengan membuat sms broadcast on schedule ( pengiriman terjadwal ) dan sms flash notifikasi yaitu sms yang dikirim langsung dapat terbuka dan dibaca dan tidak dapat disimpan. Sms broadcast ini banyak dipakai untuk pemberitahuan kepada orang banyak. 3.3 DESAIN DATABASE Dalam aplikasi Aplikasi Perpajakan SMS Gateway berbasis web ini memakai software XAMPP sebagai web servernya, dimana aplikasi dibuat dengan bahasa pemrograman PHP (PHP Hypertext Processing). Untuk itu diperlukan sebuah

17 41 database yang dibutuhkan dalam aplikasi ini, dimana table-tabel akan dibuat untuk menyimpan semua informasi dan data yang dibutuhkan Struktur Tabel Gammu Dalam aplikasi SMS Gateway ini, kita memakai Gammu sebagai library atau modul program yang menyediakan layanan interfacing antara komputer dengan ponsel/modem, dimana kita memerlukan perintah-perintah yang berkenaan dengan penerimaan dan pengiriman sms dalam membangun aplikasi SMS Gateway. Untuk itu Gammu sudah menyediakan sebuah database berikut dengan tabel-tabelnya, hal ini dibuat agar secara default, Gammu dapat berjalan dalam berbagai bahasa program atau platform apapun, baik itu web based dengan PHP atau ASP, dan juga desktop dengan menggunakan Delphi, VB atau bahasa lainnya. Dalam aplikasi SMS Gateway ini disamping tabel-tabel yang sudah ada dalam database Gammu, masih ditambahkan beberapa tabel lagi untuk keperluan sistem aplikasi, secara default tabel-tabel dalam database Gammu adalah sbb : 1. Inbox : Tabel ini berisi pesan-pesan yang yang masuk ke aplikasi ini. Field-field yang ada dalam tabel ini : - UpdatedInDB tipe timestamp - ReceivingDateTime tipe timestamp - SenderNumber tipe varchar(20) - Coding tipe enum('default_no_compression','unicode_no_compression','8bit','d efault_compression','unicode_compression') - UDH tipe text - SMSCNumber tipe varchar(20) - Class tipe int(11) - TextDecoded tipe varchar(160) - ID tipe int(10)

18 42 - RecipientID tipe text - Processed tipe enum('false','true') Dalam aplikasi ini field yang dipakai adalah ReceivingDateTime, TextDecoded, dan SenderNumber 2. Outbox : Tabel ini berisi pesan-pesan yang dikirim, cara kerjanya adalah ketika pesan dikirim keluar, pesan ini akan disimpan dalam tabel outbox dan setelah pesan berhasil dikirim maka akan dipindahkan kedalam tabel sentitems. Sehingga tabel outbox akan selalu kosong. Field-field yang ada dalam tabel ini : - Text tipe text - Coding tipe enum('default_no_compression','unicode_no_compression','8bit','d efault_compression','unicode_compression') - UDH tipe text - Class tipe int(11) - TextDecoded tipe varchar(160) - ID tipe int(10) - SequencePosition tipe int(11) 3. Pbk : tabel ini dipakai untuk menyimpan nomor telepon layaknya phonebook di handphone. Field-field yang ada dalam tabel ini : - GroupID tipe int(11) - Name tipe text - Number tipe text 4. Pbk_groups : Tabel ini berisi grup untuk nomor telepon. Field-field yang ada dalam tabel ini :

19 43 - Name tipe text - ID tipe int(11) 5. Phones : Tabel ini berisi tentang informasi telepon atau modem yang digunakan. Field-field yang ada dalam tabel ini : - ID tipe text - UpdatedInDB tipe timestamp - InsertIntoDB tipe timestamp - TimeOut tipe timestamp - Send tipe enum('yes','no' - Receive tipe enum('yes','no') - IMEI tipe varchar(35) - Client tipe text - Battery tipe int(11) - Signal tipe int(11) - Sent tipe int(11) - Received tipe int(11) 6. Sentitems : Tabel ini berisi pesan yang sudah terkirim keluar. Field-field yang ada dalam tabel ini : - UpdatedInDB tipe timestamp - InsertIntoDB tipe timestamp - SendingDateTime tipe timestamp - DeliveryDateTime tipe timestamp - Text tipe text - DestinationNumber tipe varchar(20) - Coding tipe enum('default_no_compression','unicode_no_compression','8bit','d efault_compression','unicode_compression')

20 44 - UDH tipe text - SMSCNumber tipe varchar(20) - Class tipe int(11) NOT NULL default '-1', - TextDecoded tipe varchar(160) - ID tipe int(10) unsigned NOT NULL default '0', - SenderID tipe varchar(255) - SequencePosition tipe int(11) NOT NULL default '1', - Status tipe enum('sendingok','sendingoknoreport','sendingerror','deliveryok','deliveryfailed','deliverypending','deliveryunknown','error') NOT NULL default 'SendingOK', - StatusError tipe int(11) NOT NULL default '-1', - TPMR tipe int(11) NOT NULL default '-1', - RelativeValidity tipe int(11) NOT NULL default '-1', 7. Daemons : Tabel ini berisi informasi tentang status service gammu saat aktif. Field-field yang ada dalam tabel ini : - Start tipe text - Info tipe text 8. Gammu : tabel ini berisi informasi dan versi gammu yang dipakai. Field-field yang ada dalam tabel ini : - Version tipe int(11) Tabel Tambahan Aplikasi Pada aplikasi SMS Gateway ini kita memerlukan beberapa tambahan tabel untuk kebutuhan sistem, karena tabel-tabel gammu secara default hanya diperuntukan untuk hal-hal yang terkait penerimaan dan pengiriman sms. Kita memerlukan tabel-tabel untuk menyimpan data-data klien seperti nomor telepon,

21 45 nomor id dan data-data perpajakan. Sehingga secara logika tabel terbagi dalam dua kategori yaitu tabel untuk perintah sms dan tabel untuk data. Tabel-tabel yang disediakan oleh Gammu tidak semuanya akan dipakai dalam aplikasi ini. Hanya 3 buah tabel yang diperlukan untuk aplikasi ini yaitu tabel inbox, outbok, dan sentitems. Untuk tabel yang lainnya yang disediakan oleh Gammu sebenarnya memiliki fungsi masing-masing, namun dalam aplikasi ini, tabel-tabel tersebut tidak kita pakai karena memang secara sistem tidak diperlukan. Sebagai catatan, tabel-tabel yang diberikan secara default oleh Gammu tidak bisa kita ubah baik tipe dan struktur tabelnya, sehingga untuk pengembangan aplikasinya kita perlu menambahkan tabel-tabel yang diperlukan. Tabel-tabel tambahan yang diperlukan adalah sebagai berikut : 1. Tabel Phonebook : Tabel yang berisi untuk nomor telepon klien, nama orang, serta nama perusahaan. Gammu sebenarnya sudah menyediakan tabel pbk yang diperuntukan untuk hal ini, namun karena membutuhkan yang lebih lengkap dengan menambahkan beberapa informasi sehingga kita membuat tabel khusus untuk ini. Field-field yang ada dalam tabel ini : - Id tipe int(10) - groupid tipe varchar(10) - nohp tipe varchar(20) - nama tipe varchar(30) - perusahaan tipe varchar(40) 2. Tabel Pajak : Tabel yang memuat data perpajakan yang nantinya akan diakses oleh klien untuk mendapatkan informasi perpajakan. Field-field yang ada dalam tabel ini : - Id tipe int(10) - ID_Klien tipe varchar(10)

22 46 - Perusahaan tipe varchar(40) - Bulan tipe int(2) - PPh21 tipe varchar(15) - St21 tipe varchar(15) - Lp21 tipe varchar(15) - PPh23 tipe varchar(15) - St23 tipe varchar(15) - Lp23 tipe varchar(15) - PPh25 tipe varchar(15) - St25 tipe varchar(15) - Lp25 tipe varchar(15) 3. Tabel ID_klien : tabel ini berisi tentang ID klien. - Id tipe int(10) - ID_Klien tipe varchar(10) - Nama_per tipe varchar(40) Logical Record Structure ( LRS ) Logical record structure biasanya dipakai untuk menggambarkan hubungan antar tabel tanpa memperhatikan method relasinya, namun lebih sederhana dibandingkan Entity Relational Diagram. LRS lebih kepada hubungan antar record tabel. Phonebook Id No Hp Nama Per Grup No_id Pajak Nama Id ID_klien Nama Per Id klien Id_klien Nama Per Data Pajak pesan Inbox Id Nohp Pesan. No hp Sentitems Id No Hp Pesan.. No hp Outbox Id Nohp Pesan Gambar 3.10 LRS Database Narada

23 PENETAPAN FITUR LAYANAN APLIKASI Pada sub bab ini akan dijelaskan fitur-fitur layanan yang ada pada aplikasi SMS Gateway ini. Seperti yang sudah disebutkan pada sub bab sebelumnya, aplikasi dibuat untuk melayani permintaan informasi dan pengiriman informasi antara NPC dengan klien agar lebih mudah dan cepat Fitur Autoreply Fitur SMS Autoreply ini dimaksudkan untuk memudahkan seorang user atau admin untuk menjawab semua permintaan klien. Sesuai maksud dan tujuan aplikasi ini dibuat untuk memudahkan proses pengiriman informasi dan akses informasi klien ke NPC dan juga sebaliknya. Pada fitur ini, aplikasi memberikan pesan balasan secara otomatis sesuai dengan isi pesan yang sudah ditentukan sebelumnya, seperti dijelaskan pada sub bab sebelumnya. Pesan-pesan yang masuk tidak mengikuti format tersebut diatas, akan diberikan pesan balasan sesuai dengan kesalahan pengiriman atau bahkan tidak akan direspon oleh sistem. Dalam layanan ini pesan akan dibaca dalam suatu format, berikut contoh format-format sms yang akan dilayani dalam fitur autoreply : 1. REG Nama_perusahaan : Permintaan NO ID akses aplikasi. 2. INFO ID_Klien PPh21 Jan : Permintaan Jumlah PPh21 bulan Januari. 3. INFO ID_Klien PPh23 Jan : Permintaan Jumlah PPh23 bulan Januari. 4. INFO ID_Klien PPh25 Jan : Permintaan Jumlah PPh25 bulan Januari. 5. INFO ID_Klien Bayar21 Jan : Update Status Bayar PPh21 bulan Januari. 6. INFO ID_Klien Bayar23 Jan : Update Status Bayar PPh23 bulan Januari. 7. INFO ID_Klien Bayar25 Jan : Update Status Bayar PPh25 bulan Januari. 8. INFO ID_Klien Lapor21 Jan : Update Status Lapor PPh21 bulan Januari. 9. INFO ID_Klien Lapor23 Jan : Update Status Lapor PPh23 bulan Januari. 10. INFO ID_Klien Lapor25 Jan : Update Status Lapor PPh25 bulan Januari. Format-format sms tersebut yang akan dilayani oleh fitur sms autoreply dengan baik. Permintaan akan direspon dengan pesan balasan sesuai dengan

24 48 format sms. Sehingga disini pentingnya memakai sms terformat dalam penggunaan layanan SMS Gateway dengan fitur autoreply. Kemudahan fitur autoreply ini dalam memberikan pesan balasan cukup membantu untuk menjawab semua request dari klien Sms Broadcast Sms broadcast adalah pengiriman sms yang dikirim ke banyak nomor dalam waktu yang bersamaan. Dalam aplikasi ini fitur sms broadcast ini ditentukan dalam grup wilayah. Klien akan dibagi sesuai dengan area wilayahnya. Seperti di sebuah ponsel, dalam menu buku telepon biasanya setiap nomor kontak akan diberikan sebuah grup. Ini dimaksudkan untuk layanan sms broadcast, dimana sms bisa dikirim per grup. Untuk itu disini aplikasi akan membagi grup kedalam lima wilayah yaitu grup jakbar, jakut, jakpus, jaksel, dan jaktim. Fitur sms broadcast pada aplikasi ini pun memungkinkan mengirim sms untuk ke semua nomor yang sudah diregistrasi. Sms broadcast ini berguna untuk mengirimkan pengumuman atau pemberitahuan kepada klien yang bersifat massal, seperti jatuh tempo bayar, pengumpulan data pajak yang diperlukan, serta hal-hal yang bersifat pengumuman Fitur Autodelete Pada aplikasi ini, setiap kali pesan yang masuk terkadang sangat banyak setiap harinya. Walaupun sudah disediakan layanan untuk menghapus pesan yang ada pada kotak masuk dan terkirim. Namun dirasakan belum cukup efektif dikarenakan dilakukan satu persatu. Mungkin pada kasus tertentu diperlukan layanan autodelete pesan. Pada aplikasi SMS Gateway ini ditambahkan layanan autodelete pesan berdasarkan lama pesan. Lamanya pesan yang dihapus bisa kita sesuaikan apakah lamanya 3 hari, seminggu atau sebulan.

25 DESAIN TAMPILAN APLIKASI (INTERFACE). Pada sub bab ini akan dibahas tentang tahap-tahap perancangan desain tampilan (user interface) yang meliputi halaman-halaman aplikasi dan form-form menu input dan ubah data. Aplikasi ini dibuat dengan bahasa pemrograman PHP, dimana aplikasi dibuat dalam web based interface. Sehingga tampilan dan menu aplikasi layaknya sebuah website, dimana terdapat link-link untuk menghubungkan halaman-halaman layanan aplikasi. Untuk menjalankan aplikasi ini diperlukan sebuah browser untuk menjalankannya. Halaman halaman pada aplikasi ini dikategorikan kedalam beberapa bagian, menurut fungsi dan kegunaannya : 1. Halaman utama Halaman ini muncul ketika aplikasi dijalankan, halaman utama atau halaman awal. Untuk aplikasi ini, halaman yang dijadikan default halaman awal adalah halaman menjalankan service Gammu. Dalam aplikasi berbasis web biasanya halaman awal disebut index atau main. 2. Halaman data form Halaman data form ini adalah halaman-halaman yang berkenaan dengan data dan form. Memiliki fungsi untuk tambah, ubah, dan hapus data. Yang dikategorikan data dalam aplikasi ini adalah data klien dan data pajak. Halaman data form ini terdiri dari halaman menu data. 3. Halaman pengolahan pesan Halaman pengolahan pesan adalah halaman yang digunakan untuk mengolah pesan, baik pesan masuk maupun pesan keluar. Halaman pengolahan pesan ini terdiri dari halaman kotak masuk, halaman kirim pesan dan halaman kotak terkirim.

26 50 4. Halaman Konfigurasi Sistem Halaman konfigurasi sistem adalah halaman yang berkenaan dengan pengaturan sistem. Halaman konfigurasi sistem ini terdiri dari halaman pengaturan, halaman jalankan aplikasi, dan halaman menghentikan layanan aplikasi Desain Bagan Halaman Aplikasi Pada perancangan tampilan halaman aplikasi ini, disini akan di desain sebuah menu horizontal yang akan dimuat dalam setiap halaman. Sehingga semua halaman terkesan memiliki menu yang sama, sehingga aplikasi berjalan sederhana tanpa harus membuat menu tersendiri pada setiap halamannya. Gambar 3.11 Bagan Halaman Aplikasi Pada gambar link map aplikasi, halaman yang dimuat dalam menu utama adalah 8 (delapan) halaman utama dengan 3 buah halaman yang memiliki sub menu. Seperti dijelaskan sebelumnya, halaman-halaman ini dibagi dalam 4 jenis menurut fungsi dan kegunaannya Desain Tampilan Halaman Awal Halaman awal dalam aplikasi ini di secara default ketika dibuka menampilkan halaman untuk menjalankan service Gammu. Tujuannya adalah ketika aplikasi pertama kali dijalankan, user atau admin tidak lupa untuk menghidupkan layanan

27 51 service Gammu. Hal ini sangatlah penting agar layanan pengiriman dan penerimaan berjalan saat aplikasi sudah digunakan, dan admin atau user tidak lupa untuk mengaktifkan layanan Gammu. Gambar 3.12 Desain halaman awal Desain Tampilan Halaman Data Halaman data form memuat hal-hal yang berkenaan dengan data form seperti form tambah data, ubah data, dan hapus data. Didalam halaman ini terdiri dari beberapa sub menu seperti menu buku telepon, menu id klien dan menu data pajak Gambar 3.13 Desain Halaman Menu data Sub menu yang ada dalam Halaman Data Form :

28 52 - Buku telepon : Input, edit, dan delete data kontak klien - ID Klien : Input, edit, delete ID Klien, Input Data Pajak - Data Pajak : Edit dan Delete Data Pajak Dalam halaman menu data ini, terdapat 3 (tiga) buah sub menu yang masingmasing akan memuat halaman ID klien, Buku telepon dan Pajak. Tiap halaman akan memuat form-form pengolahan data seperti tambah, ubah, dah hapus data Halaman Buku Telepon Pada halaman buku telepon ini akan digunakan untuk menampilkan data kontak klien. Fungsinya sama seperti buku telepon dalam sebuah ponsel, menyimpan data kontak seperti nama, nomor telepon, perusahaan dan lain sebagainya. Dalam halaman ini juga disediakan tombol untuk mengubah dan menghapus data, dan disediakan satu buah link menu untuk memuat halaman input data pada bagian atas tabel. Gambar 3.14 Desain Halaman Buku Telepon Pada halaman buku akan dibuat 5 (lima) buah kolom dalam tabel untuk memuat data field nama, nomor handphone, perusahaan, grup dan satu buah kolom digunakan untuk memuat tombol untuk melakukan ubah dan hapus data. Di bagian atas tabel dibuat satu buah link menu untuk menginput data kontak baru. Menu ini akan menampilkan halaman untuk menginput data kontak. Seperti pada gambar dibawah ini.

29 53 Gambar 3.15 Desain input data kontak Pada form input diatas terdiri dari empat textbox yang digunakan untuk memasukan data nama, no hp, perusahaan, dan grup. Setelah form diisi dengan lengkap maka klik tombol simpan untuk menyimpan data kedalam tabel phonebook. Data yang sudah dimasukan ini nantinya akan ditampilkan pada halaman buku telepon. Gambar 3.16 Desain edit data kontak Pada form edit, text box pada form sudah diisi dengan data yang sebelumnya. User tinggal mengubah data yang akan diubah, lalu kembali meng-klik tombol simpan untuk menyimpan pengubahan data tersebut. Sedangkan untuk hapus data, admin atau user tinggal meng-klik tombol Delete makanya aplikasi akan melakukan perintah untuk menghapus data yang dipilih Halaman ID Klien Halaman ID Klien ini digunakan untuk menampilkan data ID Klien sama halnya seperti halaman buku telepon. Pada halaman ini disediakan menu untuk

30 54 meng-input data ID baru, serta tombol ubah dan hapus data. Namun, ditambahkan sedikit yaitu tombol input data pajak. Hal ini dimaksudkan adalah untuk memudahkan dalam proses menginput data pajak. Dalam proses menginput pajak kedua hal ini yaitu nama perusahaan dan id klien harus diketahui saat melakukan input data pajak. Untuk itu pada halaman ID Klien disediakan tombol untuk menginput data pajak, agar admin tidak sulit untuk mengisi nama perusahaan dan id klien. Gambar 3.17 Desain halaman ID Klien Pada desain halaman ID Klien, field yang ditampilkan adalah ID Klien dan Nama perusahaan, terdapar tiga buah tombol untuk mengubah dan menghapus data, serta tombol input pajak untuk melakukan input data pajak. Untuk tombol klik input data pajak, ketika diklik nantinya akan memuat form input data pajak. Sedangkan tombol ubah dan hapus digunakan untuk mengubah dan menghapus data yang dipilih. Satu link menu yang berada diatas tabel, adalah menu untuk memuat form input data ID baru. Gambar 3.18 Desain Input ID klien

31 55 Dalam desain form input ID diatas, data yang dimasukan adalah dua buah data yaitu Nama perusahaan dan ID klien. Klik tombol simpan untuk menyimpan data kedalam tabel ID Klien. Sedangkan untuk form ubah data, desainnya hampir sama dengan form input data ini, namun bedanya hanya textbox pada form ubah data sudah diisi dengan data sebelumnya Halaman Data Pajak Halaman data pajak digunakan untuk menampilkan data-data pajak seperti jumlah bayar pajak, status bayar dan status lapor pajak. Data-data dalam tabel pajak ini yang nantinya akan diakses oleh klien via pesan. Proses input, ubah, dan hapus data hampir sama dengan halaman data lainnya. Namun, seperti yang dijelaskan sebelumnya untuk melakukan input data pajak baru dilakukan dari halaman ID Klien sedangkan ubah dan hapus data dapat dilakukan dari halaman pajak ini. Gambar 3.19 Desain Halaman Pajak Pada tampilan halaman data pajak sebanyak 12 kolom, satu kolom dipakai untuk memuat tombol edit dan delete data. Halaman ini sama seperti halaman data lainnya hanya bedanya tidak ada link menu untuk memuat halaman input data baru. Halaman data input pajak berada pada halama ID Klien, seperti yang sudah dijelaskan sebelumnya. Untuk desain form input pajaknya adalah seperti gambar dibawah ini.

32 56 Gambar 3.20 Desain Form Input pajak Dalam desain form input data pajak ini, desainnya sama dengan form input data yang lain. Namun jumlah data yang dimasukan pada form ini cukup banyak. Untuk form edit data pajak pun sama seperti form input ini Desain Tampilan Halaman Pesan Pada halaman pengolahan pesan ini terdiri dari halaman kotak masuk (inbox), halaman kotak terkirim (outbox), halaman autoreply pesan dan halaman pengiriman pesan yang terdiri dari dua jenis yaitu halaman kirim pesan biasa dan halaman kirim pesan broadcast Halaman Kotak Masuk (Inbox) Pada halaman kotak masuk ini, akan menampilkan pesan yang masuk kedalam sms center ini. Dimana setiap pesan yang masuk akan disimpan dalam kartu telepon (sim card) lalu service Gammu yang akan mengambil dan menyimpannya dalam tabel inbox pada database. Gambar 3.21 Desain Kotak Masuk

33 57 Pada desain halaman kotak masuk diatas, selain isi pesan dan nomor telepon juga ditampilkan nama orang dan perusahaan untuk mengenali identitas pengirim serta tanggal dan jam terima untuk mengetahui informasi kapan pesan tersebut diterima. Dalam halaman kotak masuk ini disediakan satu buat tombol untuk melakukan hapus data. Walau sudah disediakan auto delete pada halaman ini Halaman Pengiriman Pesan Halaman pengiriman pesan ini digunakan oleh admin atau user untuk mengirim pesan dari aplikasi kepada klien. Pengiriman ini terbagi dalam dua jenis yaitu pengiriman biasa yang dilakukan satu persatu, ataupun pengiriman dengan layanan broadcast sms yaitu pengiriman kebanyak nomor dalam satu waktu. Gambar 3.22 Desain kotak kirim pesan Pada kotak kirim pesan ini, seperti halnya pengiriman pesan dari ponsel dengan memasukan nomor telepon dan mengetik isi pesan yang akan dikirim. Pada kotak kirim diatas terdapat keterangan maksimum panjang sms adalah 160 karakter, hal ini dimaksudkan bahwa batas pengiriman sms dalam satu kali pengiriman adalah sebanyak 160 karakter. Jika lebih, biasanya sms akan diterima secara terpotong-potong. Untuk kasus ini, biasanya dalam Gammu akan masuk kedalam bagian multipart, yaitu pengiriman pesan yang terbagi-bagi dalam beberapa bagian karena panjang pesan melebihi 160 karakter. Namun dalam aplikasi ini, kasus semacam ini tidak ditemui sehingga tidak perlu dilakukan pembahasan terperinci untuk hal ini.

34 58 Pada kotak kirim ini, ketika isi pesan sudah selesai diketik, maka klik tombol kirim pesan untuk mengirim pesan. Pada bagian dibawah halaman ini terdapat link menu untuk memuat halaman sms broadcast. Seperti gambar dibawah ini. Gambar 3.23 Desain Halaman Broadcast Pada tampilan halaman broadcast diatas, tidak perlu lagi memasukan nomor telepon karena pesan akan dikirim secara per grup. Pada bagian bawah halaman ada select box yang memuat wilayah-wilayah dari klien seperti jakbar, jaksel, jakpus, jaktim, dan jakut. Pilih wilayah yang akan dikirimkan sms, maka aplikasi akan mengirimkan pesan ke semua klien yang berada pada wilayah yang dipilih. Layanan ini pun memungkinkan pengiriman ke semua klien atau wilayah Halaman kotak terkirim (Outbox) Halaman kotak terkirim digunakan untuk menampilkan data pesan yang terkirim dalam tabel sentitems. Tampilan halaman ini hampir sama dengan tampilan halaman kotak masuk, namun pada halaman outbox ditambahkan satu kolom untuk menampilkan data status pengiriman pesan. Status ini memuat informasi apakah pesan sudah terkirim atau gagal terkirim. Hal ini penting untuk melihat status pengiriman sehingga dapat mengetahui mana pesan yang gagal dan perlu dilakukan pengiriman ulang.

35 59 Gambar 3.24 Halaman outbox pesan Pada desain tampilan halaman pesan terkirim ini. Kolom-kolomnya sama seperti pada halaman inbox. Namun, ada satu kolom yang ditambahkan dalam halaman ini, yaitu kolom status. Dalam ponsel, setiap pesan memiliki laporan pengiriman. Setiap pesan yang sudah terkirim akan mendapat laporan terkirim, dan jika gagal akan mendapatkan laporan pengiriman gagal. Dalam Gammu, pesan yang terkirim biasanya akan memiliki status SendingOKNoReport dan jika pesan gagal memiliki status SendingError Halaman Autoreply Pesan Halaman autoreply ini digunakan untuk menjawab pesan permintaan yang dikirim klien ke sistem aplikasi ini. Untuk menjalankan halaman ini, admin harus menjalankan halaman ini, dan untuk menghentikannya, admin harus menutup halaman ini. Karena layanan ini berjalan dengan memakai jeda waktu, dalam selang beberapa waktu layanan ini akan bekerja. Gambar 3.25 Halaman autoreply

36 Desain Tampilan Halaman Konfigurasi Halaman konfigurasi ini dipakai ketika aplikasi pertama kali dijalankan. Tujuannya dibuat halaman ini adalah memudahkan melakukan konfigurasi. Proses konfigurasi ini nanti akan dijelaskan lebih rinci pada sub bab pembuatan sistem. Ada lima langkah konfigurasi yang harus dilakukan. Konfigurasi ini lebih kepada konfigurasi service Gammu yang dipakai dalam aplikasi ini. Gambar 3.26 Desain Halaman Konfigurasi Pada halaman kofigurasi diatas, terdapat lima link menu yang akan memuat halaman konfigurasi berikut dengan form-form isian. Tujuan dibuat halaman konfigurasi ini agar proses ini lebih mudah untuk dilakukan daripada harus melakukan konfigurasi secara manual. Dengan halaman ini, proses konfigurasi dapat dilakukan dengan menggunakan form isian, dan user tinggal mengisi formform yang disediakan untuk melakukan konfigurasi. Setelah konfigurasi selesai dilakukan maka langkah selanjutnya masuk ke halaman jalankan aplikasi untuk mengaktifkan service Gammu. Link menu pada halaman konfigurasi ini akan memuat halaman-halaman konfigurasi dari kelima langkah yang ada pada halaman tersebut. Kelima langkah konfigurasi ini akan dijelaskan pada sub bab selanjutnya di pembuatan sistem aplikasi.