RANCANG BANGUN APLIKASI APOTEK (Studi Kasus: Apotek Ashara Husada Sidoarjo)

  RANCANG BANGUN APLIKASI APOTEK

(Studi Kasus: Apotek Ashara Husada Sidoarjo)

_{1) 2) 3)}

  

Nicko Happy Atmaja De wiyani Sunarto Ayuningtyas

Program Studi/Jurusan Sistem Informasi

Institut Bisnis dan Informatika Stikom Surabaya

  

Jl. Raya Kedung Baruk 98 Surabaya, 60298

Email : 1) nickohappy7@gmail.com , u

Abstract

  

Ashara Husada pharmacy in cooperation with health foundation of PT .Telkom Indonesia. This health

foundation formed to serve needs of health for the employees, retired employees, and their families

those residing in Sidoarjo and the surrounding areas. Ashara Husada Clinics and pharmacies are not

only serve the employees, retired employees, and families, but also commit services for the public,

which there are currently have difficulty processes to running it. The difficulty lies in the supply of

medicines which are always in shortage supply, as well as the lack of information available me dicine

stocks. The idea design of pharmacy application on ashara husada pharmacy are takes part to commit

the transaction records, handle the shortages and overage of medicine stock, as well as displaying a

graph of purchase, sale and rejection of medicine sales. With this pharmacy application, can assist the

pharmacist in purchasing of medicines up to print the transaction report. After the trialled, the

pharmacy application at ashara Husada pharmacy can record the medicine transaction. So this

application can 1) records the medicine transactions, 2) handle the shortage and overage stock of

medicines with ROP calculations, 3) Displaying a graph of sales, purchasing, stock and rejection of

medicine sales.

  Keywords: Recording of Transactions ,Reorder Point (ROP), Pharmacy Klinik dan apotek Ashara Husada pada pegawai, pensiunan, dan keluarga PT.

  terletak di Ruko Jati Kepuh Indah Blok C7, Jl. Telkom Indonesia karena klinik dan apotek Larangan, Sidoarjo. Apotek Ashara Husada Ashara Husada memiliki kerja sama dengan bekerja sama dengan Yayasan Kesehatan Yayasan Kesehatan (YAKES) PT. Telkom (YAKES) PT. Telkom Indonesia. Yayasan Indonesia. Permasalahan timbul ketika apoteker Kesehatan ini merupakan yayasan yang dibentuk saat akan melakukan penjualan tetapi obat yang untuk melayani pemenuhan kebutuhan kesehatan akan dibeli pasien tidak tersedia atau kehabisan bagi pegawai, pensiunan, serta keluarga yang stok, maka pasien harus melakukan pemesanan menjadi tanggungan pegawai PT. Telkom obat. Hal ini disebabkan oleh stok obat selalu Indonesia yang berdomisili di Sidoarjo dan mengalami kekurangan stok sehingga sekitarnya. Klinik dan apotek Ashara Husada mengakibatkan pasien harus menunggu 3 hari tidak hanya melayani pegawai, pensiunan, dan untuk obat tersedia kembali, pada proses keluarga PT. Telkom Indonesia saja, namun juga pengadaan obat apoteker tidak mampu melakukan pelayanan kesehatan bagi masyarakat menentukan jumlah pembelian setiap obat, serta umum. tidak adanya catatan baku mengenai jumlah obat yang dibeli dan yang terjual. Bila hal tersebut

  Prosedur pada apotek Ashara Husada tidak diambil tindakan maka beresiko kepada dalam penjualan obat mengutamakan pelayanan berkurangnya kepercayaan masyarakat kepada apotek bahwa apotek dinilai tidak mampu menyediakan pelayanan kesehatan masyarakat serta pemutusan kerja sama denga pihak yayasan kesehatan PT. Telkom. Bila obat tidak tersedia maka pihak apotek akan mencatat obat tersebut dan berusaha melakukan pembelian obat dengan segera untuk pasien pegawai, pensiunan dan keluarga PT. Telkom dengan jumlah penolakan rata-rata 5% dari transaksi penjualan setiap bulan. Namun untuk masyarakat umum, dalam penjualan obat kurang diprioritaskan karena bila obat tidak tersedia maka pasien umum dapat membeli di apotek lain. Sedangkan untuk penolakan layanan penjualan obat bagi pasien umum hanya dilakukan secara lisan tanpa ada catatan apapun.

  Pada proses retur obat dari pasien, pihak apotek akan menerima obat dan menanyakan alasan obat tersebut dikembalikan. Biasanya pasien mengembalikan obat karena pasien tersebut mengalami alergi terhadap pemakaian obat tertentu dan pihak apotek memberikan catatan tertentu terhadap pasien tersebut, tetapi pihak apotek tidak memberikan ganti rugi obat yang diretur oleh pasien.

  Pihak apotek dalam melakukan pembelian memastikan obat yang dibeli memiliki tanggal kadaluarsa lebih dari 1 tahun. Jika pada saat memesan obat ke pihak suplier dan obat yang dipesan apotek memiliki tanggal kadaluarsa kurang dari 1 tahun, maka suplier tersebut akan menginformasikan bahwa obat tersebut akan kadaluarsa dan pihak apotek tidak memesan obat tersebut kepada suplier tersebut dan memesan obat ke suplier lain.

  Dalam pencatatan seluruh data transaksi pembelian obat, pembelian obat, dan pesanan obat pasien YAKES dilakukan secara manual dan menggunakan dokumen konvensional yang rawan rusak dan hilang. Dengan metode pencatatan yang demikian, keakuratan data sangat diragukan karena sulitnya melakukan pengecekan transaksi penjualan obat, pembelian obat, pesanan obat, retur obat, dan penanganan obat kadaluarsa pasien YAKES dengan dokumen-dokumen yang ada. Dokumen- dokumen yang sebelumnya adalah berupa tabel excel, buku, catatan kecil untuk persediaan obat. Akibatnya tidak dapat diketahui apabila ada transaksi yang tidak tercatat atau stok obat yang tidak diketahui jumlahnya akibat tidak akuratnya dokumen-dokumen tersebut. Sehingga pelayanan terhadap penyediaan obat menjadi menurun. Bila kondisi ini dibiarkan, dapat berakibat pihak PT. Telkom akan mencabut kerja sama dengan pihak klinik dan apotek tersebut.

  Pada penelitian sebelumnya yang dilakukan oleh Ontowiryo (2012) pada klinik Ashara Husada membahas tentang pendapatan klinik Ashara Husada meliputi pelayanan kesehatan seperti pemeriksaan pasien, pelayanan laboratorium, dan transaksi penjualan obat. Penelitian tersebut bertujuan untuk membantu pihak klinik untuk mencatat transaksi pelayanan kesehatan guna menghasilkan rekap klaim pelayanan kesehatan yang akan diberikan kepada YAKES PT. Telkom, serta rekap transaksi pelayanan kesehatan pasien umum. Sedangkan pada penelitian ini hanya membahas transaksi penjualan, pembelian obat, retur obat, penanganan kadaluarsa obat dan penolakan pelayanan penjualan obat. Untuk mengatasi permasalahan pada apotek Ashara Husada diperlukan sebuah aplikasi pencatatan transaksi penjualan dan pembelian obat yang dapat membantu bagian apoteker dalam melaksanakan tugasnya untuk melakukan pencatatan transaksi penjualan, pembelian obat, retur obat dan penanganan kadaluarsa obat guna menghasilkan laporan pelayanan transaksi pasien YAKES PT. Telkom Indonesia dan pasien umum.

  METODE Tahapan SDLC

  Kebutuhan perangkat lunak dapat diartikan sebagai properti yang harus dipamerkan dalam rangka memecahkan beberapa masalah di dunia nyata (Alfarisyi, 2014). Model incremental melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem perangkat lunak yaitu tahap communication, planning,

  modeling

  , construction dan deployment Berikut ini adalah penjelasan dari tahap-tahap yang dilakukan di dalam model waterfall:

  1. Communication (komunikasi) Langkah ini merupakan analisis terhadap kebutuhan software , dan tahap untuk mengadakan pengumpulan data dengan melakukan pertemuan dengan customer, maupun mengumpulkan data-data tambahan baik yang ada di jurnal, artikel, maupun dari internet.

  2. Planning (perencanaan) Proses planning merupakan lanjutan dari proses communication (analysis requirement).

  Tahapan ini menggambarkan tugas-tugas teknis yang dilakukan, sumber daya yang dibutuhkan, produk yang harus dihasilkan, dan jadwal-jadwal kerja termasuk rencana yang akan dilakukan.

  3. Modeling (pemodelan) Proses modeling ini akan menerjemahkan syarat kebutuhan-kebutuhan menjadi sebuah perancangan software yang dapat diperkirakan sebelum dibuat coding. Proses ini berfokus pada rancangan struktural data, arsitektur

  software , representasi interface, dan detail

  (algoritma) prosedural. Pada aplikasi apotek ini menggunakan perhitungan Reorder Point

  System (ROP). Dalam sistem ROP setiap pusat

  distribusi pada tingkat lebih rendah (store or

  branch warehouse ) meramalkan permintaan

  untuk produk guna melayani pelanggannya, kemudian memesan dari pusat distribusi pada tingkat lebih tinggi (main warehouse) apabila kuantitas dalam stok pada pusat distribusi yang lebih rendah (branch warehouse) mencapai ROP (Gaspersz, 2004). ROP diterapkan untuk setiap stockkeeping unit

  (sku) sebagai ramalan permintaan selama

  waktu tunggu pengisian (panjang waktu tunggu untuk resupply dari wholesale, atau area atau warehouse ditambah stok pengaman). ROP dan stok pengaman ditentukan secara konvensional. Sistem ini dapat menghasilkan permintaan yang sangat bervariasi di pusat distribusi pada tingkat yang lebih tinggi (central warehouse) karena hanya memiliki interaksi yang kecil atau sedikit di buah, maka perhitungan ROP untuk obat antara branch warehouse dan central Cardivask sebagai berikut

  warehouse, sehingga membutuhkan stok

  DLT = total permintaan

• – persediaan pengaman yang relative besar pada central

  = 450

• – 390 = 60 Tablet

  warehouse di samping stok pengaman pada branch warehouse.

  SS = 20 Tablet ROP = DLT + SS (10)

  Pada proses pengadaan obat terdapat perhitungan ReOrder Point(ROP) yang berguna ROP = 60 tablet + 20 tablet untuk menentukan pada jumlah berapa obat harus

  ROP = 80 tablet melakukan pengadaan kembali. Gambar di

  4. Construction (konstruksi) bawah ini merupakan flowchart perhitungan dari ROP. _mulai Construction merupakan proses membuat

• _{- Int ROP, DLT, SS, inventori penerjemahan desain dalam bahasa yang bisa} kode. Coding atau pengkodean merupakan _DLT

  dikenali oleh komputer. Programmer akan menerjemahkan transaksi yang diminta oleh _{ROP = DLT + SS} user . Tahapan inilah yang merupakan tahapan _ROP secara nyata dalam mengerjakan suatu

  software , artinya penggunaan komputer akan _selesai dimaksimalkan dalam tahapan ini. Setelah pengkodean selesai maka akan dilakukan

  Gambar 1 Gambar Flowchart

  testing terhadap perangkat lunak yang telah

  Perhitungan ReOrder Point ROP = DLT + SS dibuat tadi. Tujuan testing adalah menemukan

  Titik Pemesanan Kembali

  ROP =

  kesalahan-kesalahan terhadap perangkat lunak (Reorder Point) tersebut untuk kemudian bisa diperbaiki.

  DLT = Permintaan Selama

  Waktu Tunggu (Demand

  5. Deplyoment (pengoperasian)

  During Lead Time ) SS = Stok Pengaman (Safety Stock )

  Tahapan ini bisa dikatakan akhir dalam Untuk contoh perhitungan dari metode ROP ini pembuatan sebuah software atau sistem. kita mengambil contoh data pembelian dan

  Setelah melakukan analisis, desain dan penjualan obat pada bulan Maret 2014. Misalnya pengkodean maka sistem perangkat lunak kita akan menghitung obat Cardivask . Pada data yang sudah jadi akan digunakan oleh user. persediaan terdapat 390 tablet obat namun

  Kemudian software yang telah dibuat harus terdapat permintaan obat sampai 450 sehingga dilakukan pemeliharaan secara berkala. permintaan yang belum tercukupi sebanyak 60 tablet dan diketahui stok pengaman sebanyak 20 Pembelian Obat Analisis Dan Perancangan Sistem _{Apotek Supplier} Aliran Sistem Proses Pembelian Obat _{Data obat Mulai Transaksi penjualan Data penolakan}

  Pada aliran system proses pembelian obat _{Penjualan Obat Pesanan obat Hitung ROP} proses diawali dengan sistem terlebih dahulu _ROP membaca data dari tabel data obat, data _{Pilih obat yang akan dibeli Simpan ROP} penolakan transaksi penjualan, penjualan obat, _{Simpan Surat pengadaan Jumlah Simpan ROP ROP} dan pemesanan obat untuk menentukan ReOrder _{Data pembelian obat Pemesanan Obat} (ROP) di mana ROP ini berfungsi untuk

  System _{Pemesanan Obat Cetak Surat}

  menentukan jumlah obat yang harus melakukan _{Surat Pemesanan Surat Pemesanan Obat Obat} pembelian kembali. Setelah ROP diperoleh maka _{pembayaran Melakukan Menyerahkan Obat obat Tidak Kadaluarsa?} akan muncul obat apa saja yang harus dilakukan _Pembayaran pembelian, memasukkan jumlah obat yang akan _{Simpan transaksi pengadaan obat Bukti pembayaran Data pembelian obat Membuat bukti pembayaran} dipesan yang kemudian data tersebut disimpan ke _{pembelian Data obat Transaksi Obat} dalam tabel penjualan obat. Setelah itu pihak _{Perbarui data obat} apoteker mencetak surat pemesanan obat dan _{Update stok obat} kemudian memberikan kepada pihak supplier. Data obat _{Selesai Ya} Setelah supplier menerima surat pemesanan obat, supplier melakukan pengecekan apakah obat

  Gambar 3 Aliran Sistem Proses Pembelian Obat yang dipesan mendekati kadaluarsa obat atau

  Aliran Sistem Proses Penjualan Obat

  tidak, bila telah mendekati kadaluarsa maka Pada aliran sistem proses penjualan obat supplier memberikan informasi bahwa obat yang proses diawali dengan proses pengecekan dipesan akan kadaluarsa dan apoteker dapat persediaan obat, jika obat tersedia apakah pasien memesan obat ke supplier lain. Jika tidak, merupakan pasien pegawai, pensiunan atau supplier memberikan obat dan apoteker termasuk keluarga PT. Telkom atau pasien melakukan pembayaran. Kemudian apoteker umum. Jika termasuk pasien pegawai PT. menyimpan transaksi pembelian obat tersebut

  Telkom maka apoteker langsung menyimpan data pada tabel transaksi pembelian. Kemudian penjualan pasien PT. Telkom. Jika pasien umum, apoteker memperbarui data obat pada tabel stok apoteker menghitung total harga yang dibayar obat. oleh pasien yang kemudian menyimpan data penjualan tersebut ke dalam tabel transaksi penjualan. Jika obat tidak tersedia, maka pasien dapat memesan obat tersebut. Ketidaktersediaan obat dikarenakan obat yang dipesan biasanya tidak terdaftar pada Daftar Obat Telkom, sehingga pasien harus memesan terlebih dahulu.

  Penolakan Penjualan Obat

  Jika pasien bersedia memesan dan menunggu _{Apotek Pasien} obat, maka apoteker memasukkan data obat dan _Mulai data pasien dan menyimpan data tersebut ke _{1 Resep} dalam tabel pemesanan obat. Kemudian mencetak data tersebut yang kemudian diberikan _Resep kepada pasien. Bila pasien tidak bersedia _Resep memesan dan menunggu obat maka pasien dapat _{Simpan data obat yang tidak terlayani Resep} membeli obat pada apotek lain, namun apoteker _{Data penolakan transaksi Resep} akan mencatat penolakan penjualan obat pada _penjualan proses penolakan penjualan obat. _{Penjualan Obat Selesai Pasien Apotek} Gambar 5 Aliran Sistem Proses Penolakan _{2 Mulai} Penjualan Obat. _{Resep Data Obat} Aliran Sistem Proses Menampilkan Obat Kadaluarsa _{Pasien Cek persediaan} Pada aliran sistem proses menampilkan obat _{Hitung Total Obat Tidak Ya Menunggu Pegawai Telkom transaksi pembelian, stok obat yang kemudian Data Obat Ya Ya Simpan Transaksi Penjualan Tersedia? Tidak Tidak} kadaluarsa ini sistem akan membaca tabel _{Pembayaran kadaluarsa obat. Kemudian data obat yang Nota Penjualan Obat Total pembayaran Penjualan Transaksi Penjualan Obat Simpan pesanan Cetak Nota Penjualan Transaksi Data obat pasien obat 1} sistem akan melakukan pengecekan tanggal _{1 Pesanan obat} kadaluarsa akan muncul. _{Pesanan obat Nota Penjualan Obat Selesai Copy resep Cetak Pesanan Pesanan obat Obat 1} Kadaluarsa _{Apotek Mulai Pembelian} Transaksi _{Data Obat}

  Gambar 4 Aliran Sistem Proses Penjualan Obat _{Tidak Cek tanggal kadaluarsa}

  Aliran Sistem Proses Penolakan Penjualan _{Kadaluarsa? Ya} Obat _{Data obat kadaluarsa}

  Pada proses aliran sistem ini merupakan _cetak lanjutan dari aliran sistem penjualan obat. Proses ini diawali dengan proses memasukkan data obat Obat kadaluarsa yang terdapat pada resep dan menyimpan data _Selesai tersebut pada tabel penolakan transaksi

  Gambar 6 Aliran Sistem Proses Menampilkan penjualan. Kemudian resep diberikan kembali Obat Kadaluarsa kepada pasien. Menampilkan Data Aliran Sistem Proses Retur Obat _Apotek

  Pada aliran sistem proses retur obat, pasien _{Mulai Data obat} memberikan obat yang diretur. Setelah itu _{Transaksi penjualan} apoteker memasukkan data obat yang diretur, Pilih Menu _{Menampilkan Data Pesanan Transaksi penjualan Data Penolakan} kemudian sistem menampilkan data transaksi _obat penjualan, kemudian apoteker memasukkan data _{yang terjual Data Obat Data Obat yang Data Obat tidak perbulan dicari perbulan terpenuhi dan yang sering Stok obat} keluhan obat pasien ke dalam tabel pasien dan disimpan. Obat yang diterima apoteker selanjutna Cetak data akan disimpan namun tidak dijual kembali dan _{Data Obat yang Data Obat yang Data Obat yang terjual terpenuhi dan tidak sering sering dicari Stok obat} biasanya untuk dihancurkan atau dikembalikan _Selesai kepada supplier. _{Retur obat}

  Gambar 8 Aliran Sistem Proses Menampilkan _{Pasien Apotek Mulai Data Obat} Data

  Obat _{pasien Tampilkan data Penjualan Transaksi Obat retur Keterangan Keluhan obat Tampilkan Form Form Retur Retur Obat Obat} Penjualan Obat _{Ya 2 penjualan? Obat Transaksi Tidak} Simpan data _{Retur obat Selesai}

  Gambar 7 Aliran Sistem Proses Retur Obat

  Aliran Sistem Proses Menampilkan Data

  Pada aliran proses menampilkan data, apoteker memilih menu terlebih dahulu untuk menampilkan data yang ingin ditampilkan, data yang ditampilkan tersebut dapat dicetak. Berikut gambar aliran sistem proses menampilkan data.

  Gambar 9 Context Diagram butir obat dengan menggunakan perhitungan

  

Model Data Konseptual ROP. Sistem menangani kekurangan obat dengan

_{rop total_permintaan Integer rop Integer user_id <pi> Serial <M> ss Integer periode Date <M> rop_id <pi> Serial <M> rop_pk <pi> username Variable characters (255) <M> stok Integer OK pada warning tersebut maka akan langsung bentuk_obat_pk <pi> bentuk Variable characters (100) <M> nama Variable characters (255) <M> bentuk_obat_id <pi> Serial <M> nik Variable characters (25) <M> bentuk_obat apoteker_id <pi> Serial <M> no_ktp Variable characters (20) <M> apoteker_pk <pi> hire_date Date apoteker user adalah karyawan password Variable characters (255) <M> user_pk <pi> user} menampilkan warning dan bila menekan button _{penolakan_id <pi> Serial <M> no_penolakan Integer <M> obat_pk <pi> tanggal_penolakan Date & Time penolakan_pk <pi> menjual melakukan pembelian penolakan perhitungan rop obat tanggal_kadaluarsa Date nama Variable characters (100) <M> obat_id <pi> Serial <M> stok_total Integer noreg Variable characters (25) <M> penggunaan obat obat obat apa saja yang diretur dilihat pada gambar 13 dan 14.} muncul form pemesanan. Hasil uji coba dapat penjualan yang tertolak melakukan pemesanan obat _{no_penjualan Variable characters (25) <M> penjualan_pk <pi> tanggal_penjualan Date & Time <M> penjualan_id <pi> Serial <M> penjualan no_retur Variable characters (25) <M> no_pesanan Variable characters (25) <M> pesanan_id <pi> Serial <M> pesanan pengadaan ada yang dari pemesanan ada yang tidak penjualan yang diretur no_pembelian Variable characters (25) <M> pembelian_id <pi> Serial <M> tanggal_pembelian Date & Time <M> pembelian retur_pk <pi> tanggal_retur Date & Time <M> retur_id <pi> Serial <M> retur penjualan obat ke pasien nama Variable characters (255) <M> retur obat oleh pasien pesanan_pk <pi>} tanggal_pesanan Date & Time <M> _{no_ktp Variable characters (20) <M> kode Variable characters (50) pasien_id <pi> Serial <M> Memesan_Obat pasien pembelian_pk <pi>} pasien_pk <pi> _{jenis_pasien_pk <pi> jenis_pasien Variable characters (50) <M> jenis_pasien_id <pi> Serial <M> jenis pasien jenis_pasien}

  Gambar 11 ERD CDM _{apoteker_id integer <pk> apoteker} Gambar 13 Gambar Hasil Uji Coba Penanganan _{rop integer rop_id integer <pk> stok integer total_permintaan integer ss integer periode date obat_id integer <fk> rop FK_ROP_PERHITUNG_OBAT user_id integer <pk> bentuk varchar(100) bentuk_obat_id integer <pk> FK_OBAT_PENGGUNAA_BENTUK_O apoteker_id integer <fk> bentuk_obat FK_USER_USER_ADAL_APOTEKER no_ktp varchar(20) nama varchar(255) nik varchar(25) hire_date date user} Stok Dengan Menggunakan Perhitungan ROP (1) _{FK_OBAT_MENJUAL_PENJUALA tanggal_kadaluarsa date nama varchar(100) noreg varchar(25) penjualan_id integer <fk2> bentuk_obat_id integer <fk1> obat_id integer <pk> stok_total integer obat password varchar(255)} username varchar(255) _{FK_RETUR_OBAT_APA__OBAT FK_PEMBELIA_MELAKUKAN_OBAT retur_id integer <pk> retur tanggal_penjualan timestamp no_penjualan varchar(25) pas_pasien_id integer <fk> penjualan_id integer <pk> penjualan FK_PESANAN_MELAKUKAN_OBAT pesanan_id integer <pk> obat_id integer <fk1> pesanan FK_PEMBELIA_PENGADAAN_PESANAN FK_RETUR_PENJUALAN_PENJUALA obat_id integer <fk3> obat_id integer <fk2> pes_pesanan_id integer <fk1> pembelian_id integer <pk> pembelian} pas_pasien_id integer <fk2> _{pen_penjualan_id integer <fk1> no_retur varchar(25) tanggal_retur timestamp FK_PENOLAKA_PENJUALAN_PENJUALA} pas_pasien_id integer <fk2> _{tanggal_pesanan timestamp no_pesanan varchar(25) tanggal_pembelian timestamp no_pembelian varchar(25) penjualan_id integer <fk> penolakan_id integer <pk> no_penolakan integer penolakan FK_PESANAN_MEMESAN_O_PASIEN} Gambar 14 Gambar Hasil Uji Coba _{tanggal_penolakan timestamp FK_PENJUALA_PENJUALAN_PASIEN kode varchar(50) Perhitungan ROP (2) no_ktp varchar(20) jen_jenis_pasien_id integer <fk> pasien_id integer <pk> nama varchar(255) FK_PASIEN_JENIS_PAS_JENIS_PA pasien FK_RETUR_RETUR_OBA_PASIEN} Penanganan Stok Dengan Menggunakan _{jenis_pasien varchar(50) jenis_pasien_id integer <pk> jenis_pasien} Untuk selanjutnya adalah grafik yang berfungsi untuk menampilkan data transaksi yang Gambar 12 ERD PDM telah disimpan pada database yang telah dibuat.

  Berikut gambar grafik pada aplikasi apotek ini.

HASIL DAN PEMBAHASAN

  Pada uji coba menunjukkan bahwa sistem dapat menangani kekurangan stok obat ketika obat telah mencapai di bawah stok aman yaitu 20 Gambar 15 Gambar Tampilan Grafik Aplikasi Apotek.

  KESIMPULAN

  Sesudah melakukan analisis, perancangan, uji coba dan evaluasi sistem, maka dapat diambil beberapa kesimpulan, yaitu:

  1. Aplikasi yang dibuat mampu mengurangi jumlah penolakan penjualan obat.

  2. Aplikasi yang dibuat mampu memberikan informasi pembelian obat, penjualan obat, stok obat dan penolakan transaksi penjualan obat.

  3. Aplikasi yang dibuat mampu menampilkan grafik dari transaksi penjualan obat, pembelian obat, stok obat dan penolakan penjualan obat.

DAFTAR PUSTAKA

  Gaspersz, V. (2004). Production Plan &

  Inventory Control. Jakarta: Gramedia