Dokumentasi Sistem Informasi Keuangan Sport Club
Oleh: A. Sasmito Adibowo – 1299000029 Freddy Priyatna - 1299000363 Hansen Wiriadinata – 129900038X Julius Liman - 1299000525 Jutedy - 1299000533 Tunggul Simbolon - 1299000967
Fakultas Ilmu Komputer Universitas Indonesia 2001
I. Requirement Analysis Process Karena modul yang akan dikerjakan oleh kelompok kami adalah modul keuangan (financial), kami berasumsi bahwa segala transaksi keuangan yang terjadi di klub olahraga Sport Club adala h berdasarkan pada prinsip akuntansi. Hal ini dilakukan agar laporan keuangan yang disampaikan kepada general manager Sport Club adalah benar adanya, tanpa manipulasi dari pihak-pihak teller yang berhubungan dengan transaksi keuangan di Sport Club. Dengan berdasarkan prinsip akuntansi, laporan keuangan yang disampaikan pun akan bersifat formal dan profesional untuk sebuah klub olahraga di dalam mengimplementasikan sistem informasi secara keseluruhan. Untuk itulah, kami mendatangkan beberapa narasumber dari Fakultas Ekonomi Universitas Indonesia, yang juga merupakan teman dari salah satu anggota kelompok untuk menganalisa kebutuhan sistem informasi keuangan secara lengkap dari proses seseorang melakukan transaksi keuangan sampai bagaimana caranya menghasilkan suatu laporan keuangan yang seimbang. Dari hasil analisa kebutuhan inilah, selain sebagai bahan untuk proses analisa dan model pada tahap selanjutnya, kami juga mendapatkan pengalaman bahwa dalam pengembangan suatu sistem informasi atau perangkat lunak, kami sebagai pengembang tidak dapat berdiri sendiri untuk mengimplementasikan sistem informasi. Contohnya, kami memerlukan komunikasi yang efektif dengan end user untuk mengetahui kebutuhan apa yang mereka inginkan dan diimplementasikan pada sistem informa si yang akan dikembangkan. Inilah hal yang cukup signifikan yang perlu dicamkan dalam tahap analisa kebutuhan dimana kami mengumpulkan semua keinginan dan kebutuhan end user, dalam hal ini klub olahraga Sport Club, untuk di-develop dan diimplementasikan pada sebuah sistem informasi. Kami melakukan beberapa pendekatan yang berbeda di dalam mengumpulkan kebutuhan sistem. Dalam hal ini, yang merupakan narasumber kami adalah teman-teman dari FE UI yang memang mengetahui prinsip akuntansi. Pendekatan yang dilakukan ialah dengan cara: ? Mengajukan pertanyaan-pertanyaan baik melalui e-mail dan pertemuan langsung dengan narasumber tersebut atau wawancara. Wawancara yang dilakukan ialah dengan menanyakan hal- hal yang paling umum sampai pada hal yang men-detail dari prinsip akuntasi dikaitkan dengan sistem informasi. Adapun pertanyaan-pertanyaan yang diajukan misalnya, “Terdiri dari apa saja laporan- laporan keuangan?”, “Kalau seorang pelanggan membayar uang les, uang tersebut dimasukkan ke laporan manakah?”, “Apakah klub olahraga akan mengalami kerugian jika beban lebih besar dari pendapatan, apakah harta-harta tidak bergerak, misalnya klub olahraga dapat dimasukkan sebagai suatu pendapatan juga?”, “Bagaimana caranya suatu transaksi keuangan dapat dikatakan valid?” ? Mengadakan suatu sesi formal dengan narasumber dimana kami berdiskusi tentang prinsip akuntansi dilihat dari sudut sistem informasi yang akan dikembangkan. Kami merasa dengan melakukan cara-cara tersebut di atas, kami telah berhasil mengumpulkan kebutuhan-kebut uhan sistem yang akan kami analisa selanjutanya pada tahap berikut. Hasil analisa kebutuhan adalah sebagai berikut: ? Di dalam prinsip keuangan, terdapat berbagai laporan yang mempunyai fungsi yang berbeda-beda. Laporan akuntasi tersebut ialah 1. Jurnal keuangan, berguna untuk menampilkan data akuntansi yaitu data peralatan, hutang, prive, penambahan modal, kas, modal, pendapatan, beban dan pajak pada periode bulan tertentu 2. Neraca keuangan, berguna untuk untuk menampilkan informasi akuntansi berupa neraca keuangan dalam periode bulan tertentu. Terdiri dari 2 jenis data, yaitu data akuntansi aktiva dan tanah dan data akuntasi passiva. Data akuntansi
aktiva terdiri dari kas, gedung, peralatan sedangkan data akuntansi passiva terdiri dari hutang dan modal 3. Laporan rugi laba, berguna untuk menampilkan informasi akuntansi berupa laporan rugi laba dalam periode bulan tertentu. Laporan rugi laba bermanfaat untuk menampilkan data beban dan pendapatan. Jika pendapatan lebih besar dari beban, maka akan mendapatkan laba sedangkan jika beban lebih besar dari pendapatan, maka akan mengalami kerugian 4. Laporan perubahan modal, berguna untuk menampilkan informasi akuntansi berupa laporan perubahan modal dalam periode bulan tertentu 5. Laporan pajak, berguna untuk menampilkan data-data pajak dalam periode tahun tertentu 6. Laporan modal, berguna untuk menampilkan data-data modal dalam periode tahun tertentu. Laporan modal terdiri dari laporan prive dan laporan penambahan modal 7. Laporan depresiasi, berguna untuk menampilkan nilai depresiasi suatu barang pada data keuangan. Syarat untuk melakukan depresiasi adalah pemakaian barang yang mau dilakukan depresiasi harus lebih dari 1 tahun. Setiap kali depresiasi barang mengurangi harga beli dengan 10% dari harga beli. Namun, jika jumlah depresiasi telah mencapai (estimasi pemakaian barang - 1), maka tidak dapat lagi dilakukan depresiasi ? Hirarki- hirarki data-data akuntansi utama beserta constraint yang berlaku pada data tersebut. Hirarki data-data akuntansi beserta constraint adalah sebagai berikut: Peralatan Tetap
Inventory
Tanah
Land
Gedung
Building
Perlengkapan
Supplies
Harta [D]
Lancar
Kas
Money_on_hand
Piutang
account
Bank_Account_Paybale
Utang [K]
Utang Bank Inventory_Account_Payable
Modal [K]
Beban [D]
Modal
Capital
expense
Pendapatan di muka Pendapatan [K]
Revenue
Pendapatan biasa Pendapatan bunga
Di tahap analisa kebutuhan ini, kami juga menerbitkan sebuah whitepaper yang berisi spesifikasi proyek secara keseluruhan karena proyek ini akan dikembangkan oleh berbagai kelompok. Dalam whitepaper ini dijelaskan secara terperinci hubungan masing- masing modul dengan modul keuangan yang akan kami kembangkan. Whitepaper ini bertujuan sebagai bahan acuan yang akan dipakai untuk integrasi modul pada akhir proyek karena di dokumen ini juga berisi standar-standar bahasa yang dipakai, konfigurasi DBMS dan task set selector yang memberikan gambaran degree of rigor yang akan dipakai. Karena task set selector yang didapatkan adalah 1.9 maka degree yang dipakai ialah pendekatan secara structured. Berikut adalah whitepaper yang dimaksud: ----------------------------------------------------------------------------------------------------------------
Sports Club Information System Whitepaper Draft Abstract This document serves as a preliminary documentation for the Sports Club Information System project group. It defines standards of practices and project specification. The current version is only a draft and is subject to change during the development process.
Definition of Terms project group
The entire set of people working on the system.
module team
The set of people working on a primary module. The team is led by a team manager.
t imestamp
a unit of time which records year, month, day, hour, minute, and second of a particular instance of time.
primary module
one of financial, staff facility, or courses module s.
Goal The goal of the project is to create a commercial-grade entry-level information system for a sports club.
System Structure The system is client/server based with thick clients managing a single database. The database will be an off-the-shelf DBMS while the clients are custom-made. The clients consist of several primary modules, each of which are assigned one module team.
Financial Module The financial module manages most financial-related activities of the sports club. It serves to ease the task of recording and analyzing the club's financial status for a period. It could assess the club's identify profit and losses. The module consists of several executable programs, each of which are designated for a particular department:
Accounting Department This module will record every events which update accounting entities such as money on hand, account receivable, account payable, etc. The updates are the foundation to generate Journal, LossBenefit Balance and Capital Balance. Other modules will interface to the financial modules by using the take_money/give_money protocol : Staff module is concerned with the total of staffs’ salaries and separation pay for fired staff. Staffs’ salaries and separation pay request events will interface financial modules by using take_money protocol. Facility module is concerned with income which is gained from facilities’ fee,
facilities’
maintenance costs and total expense to buy these facilities. Income payment events will use give_money protocol. Maintenance costs and expenses to buy facilities request events will use take_money protocol to interface financial modules. Courses Module is concerned with total of trainers’ salaries, separation pay for fired trainer and income from courses. Trainer’s salaries and separation pay request events will interface financial modules by using take_money protocol. Income payment events will use give_money protocol. Membership Module is concerned with income from membership fee. Income payment events will use give_money protocol.
Design Philosophies
Documentation Languages All the documentation for clients will be written in Bahasa Indonesia while the developer side will be written in English. The reason for this separation is that the end-user will be a typical nontechnical Indonesian; while technical terms are more expressible in English such that technic al documents can be written without introducing nonstandard terms.
Database Design All entities that have a time attribute by nature will have a timestamp attribute in the database. Examples of such entities are: $ Member – the member's registration date (also record the time). $ Staff – the enrollment date. $ Equipment – the purchase date. The database consists of two large table entity types which refers to the entities in the club: accounting side and physical side. The accounting side entities records accounting information for the entities, such as purchase price and depreciation accumulation. The physical side records real attributes that are attached to the entity, such as color, weight, etc.
Integration The system will be loosely-coupled. Integration between primary modules will be done at the database level. The primary modules shall share a single database schema and coordinate record sharing/locking among themselves (the modules may or may not share a single user-id/password combination, depending on the DBMS used). Each primary module shall maintain data integrity at each transaction. User interfaces should be similar among primary modules. The modules should share a same lookand-feel to ease the user's transition between modules. The look-and-feel should also be intuitive and similar to other Windows™ applications to ease the user in learning the system. The system should share a common logo, a similar splash screen and a similar About Box. The program icons should also be standardized.
Configuration The system should be as configurable as possible. All modules should have the same configuration repository (e.g., same Windows registry path). The configuration information stored are, among others, $ The database connection information (ODBC connect string, user-id/password combination). $ The sports' club name. Adaptation Criteria
Grade
Weight
EPM
Product
Size of project
1
0.90
1
0.90
Number of users
2
0.97
1
1.94
Business critically
4
1.20
1
4.80
Longevity
1
1.20
1
1.20
Stability of requirements
2
0.95
1
1.90
Ease of communication
3
0.90
1
2.70
Maturity of technology
1
1.20
1
1.20
Adaptation Criteria
Grade
Weight
EPM
Product
Performance constraints
1
0.80
1
0.80
Embedded/nonembe dded
1
0.80
1
0.80
Project staffing
1
1.10
1
1.10
Interoperability
5
1.10
1
5.50
Reengeneering factors
3
1.00
0
0.00
Task set selector
1.90
Development Culture The development will be approached in a structured manner. Team managers shall meet at every week reporting their team's progress and discussing conflicts. Informal communication among project members discussing the project is encouraged. ------------------------------------------------------------------------------------------------------------------------
II. Analysis Process and Modelling Proses analisa yang kami gunakan adalah berdasarkan proses evolutionary atau iterative dimana pengembangan sistem dibagi atas beberapa tahapan, yaitu proses analisa kebutuhan, proses analisa, proses design, proses implementasi dan proses testing. Namun di setiap proses tahapan tersebut, dapat kembali ke tahapan sebelumnya jika dirasakan perlu diadakan revisi atau kebutuhan baru yang akan mempengaruhi keseluruhan sistem. Berdasarkan hasil kebutuhan yang telah dikumpulkan pada tahapan requirement analysis process, maka langkah pertama yang dilakukan adalah mendisain suatu Entity Relationship Diagram (ER diagram) yang merupakan diagram hubungan antara data dan relasi pada sistem informasi keuangan Sport Club. Kemudian juga dihasilkan Data Flow Diagram yang merupakan diagram aliran data-data akuntansi pada sistem informasi keuangan. DFD digambarkan dalam bentuk level 0 dan level 1.
Diagram ER tersebut adalah sebagai berikut: fin_inventory_account_payable
fac_inventory
fin_depreciation_expense
id timestamp value inventory_id
id purchase_value expected_lifetime
id value
fin_inventory fac_land
id timestamp inventory_id value
id
fac_building id purchase_value expected_lifetime
fin_land id timestamp land_id value
fin_building
fin_money_on_hand
id timestamp building_id value
id timestamp amount account_type requester_person requester_department
fin_bank_account_payable fin_account_receivabe
id timestamp value
id timestamp value
fin_expense
fin_supplies
fin_revenue
id timestamp value
id timestamp supplies_id value
id timestamp value
fac_supplies id
Secara garis besar, diagram berwarna transparan adalah diagram ER untuk modul keuangan sedangkan diagram berwarna gelap adalah tabel pada diagram ER pada modul lain yang mempunyai hubungan dengan diagram ER kami. Diagram ER ini didapatkan dari hasil analisa kebutuhan yang telah disebutkan di atas. Masing- masing laporan keuangan dimapping menjadi satu tabel dan di antara tabel- tabel tersebut terdapat hubungan-hubungan yang berkaitan satu dengan yang lainnya. Kemudian, kami juga mendisain Data Flow Diagram dari sistem informasi keuangan Sport Club yang menandakan aliran data-data akuntansi di keseluruhan sistem informasi tersebut.
DFD level 0 adalah sebagai berikut: Facility Subsystem
Member Subsystem
non-op income
expense
income
income
Staff Subsystem
expense
Accountant
prive
depreciation tax exp expense
Accountant
financial snapshot
General Manager
Accountancy Subsystem
income expense
Course Subsystem
financial report
investment
capital changes
DFD level 1 adalah sebagai berikut: decode fac income
income
Facility Subsystem
non-op income insert debit
expense decode fac expense
non operational income
data Non - operational Income
c c
decode fac non-op income Income
d
Member Subsystem
income
decode mbr income
income insert credit
c
data
d
Staff Subsystem
expense
decode stf expense
c
d
d
c
expense insert debit
d decode crs income
income
Course Subsystem
Expense
d
expense decode crs expense
d
c
d money on hand insert debit
d c
decode acc tax
decode acc depreciation
inventory insert debit
depreciation
Accountant
appreciation
decode acc appreciation
d c
d
investment capital changes
data Inventory
inventory insert credit
c
d
c decode acc investment
capital insert debit
data
data Capital
c decode acc capital changes
data
c
prive decode acc prive
data Money on hand
money on hand insert credit
c tax
data
d
capital insert credit
data
Lanjutan DFD Level 1 Non - operational Income
Accountant
assess
Income
assess
create Profit Loses Report
assess
formatted report report
create Capital Changes Report
assess assess report Expense
create Financial Journal
assess
report
report report report
assess
Money on hand
report format financial report
report report
assess
format financial report
assess create Balance Sheet
assess assess
report formatted report
Inventory
assess
General Manager
Capital
III. Design Process Hasil analisa di atas kemudian di- mapping pada tahapan design. Adapun langkah yang pertama kali ditempuh pada tahapan ini adalah mendeklarasikan Data Definition Language (DDL) yang berdasarkan pada diagram ER yang telah dianalisa pada tahapan analisa. DDL tersebut adalah sebagai berikut: CREATE TABLE fin_capital_reinvest ( fin_cap_reinvest_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, PRIMARY KEY (fin_cap_reinvest_id) ); CREATE TABLE fac_inventory ( fac_inventory_id INTEGER NOT NULL, fac_name VARCHAR2(40) NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, lifetime INTEGER NOT NULL, status VARCHAR2(8) NOT NULL, PRIMARY KEY (fac_inventory_id) ); CREATE TABLE fin_inventory ( fac_inventory_id INTEGER NOT NULL, last_depreciation DATE,
current_value INTEGER NOT NULL, fin_dep_counter SMALLINT NOT NULL, PRIMARY KEY (fac_inventory_id), FOREIGN KEY (fac_inventory_id) REFERENCES fac_inventory on delete cascade ); CREATE TABLE fin_capital ( fin_capital_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, PRIMARY KEY (fin_capital_id) ); CREATE TABLE fin_prive ( fin_prive_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, PRIMARY KEY (fin_prive_id) ); CREATE TABLE fin_account_payable ( fin_accpay_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, PRIMARY KEY (fin_accpay_id) ); CREATE TABLE fin_inv_acc_pay ( fin_accpay_id INTEGER NOT NULL, fac_inventory_id INTEGER NOT NULL, PRIMARY KEY (fin_accpay_id, fac_inventory_id), FOREIGN KEY (fin_accpay_id) REFERENCES fin_account_payable on delete cascade, FOREIGN KEY (fac_inventory_id) REFERENCES fin_inventory on delete cascade ); CREATE TABLE fin_expense ( fin_expense_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, source_table VARCHAR2(40) NOT NULL, PRIMARY KEY (fin_expense_id) ); CREATE TABLE fin_money_on_hand ( fin_moh_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, PRIMARY KEY (fin_moh_id) ); CREATE TABLE fin_moh_inv ( fin_moh_id INTEGER NOT NULL, fac_inventory_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fac_inventory_id), FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade, FOREIGN KEY (fac_inventory_id) REFERENCES fin_inventory on delete cascade ); CREATE TABLE fin_revenue ( fin_revenue_id INTEGER NOT NULL,
timestamp DATE NOT NULL, value INTEGER NOT NULL, source_table VARCHAR2(40) NOT NULL, PRIMARY KEY (fin_revenue_id) ); CREATE TABLE fin_moh_prive ( fin_moh_id INTEGER NOT NULL, fin_prive_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fin_prive_id), FOREIGN KEY (fin_prive_id) REFERENCES fin_prive on delete cascade, FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_moh_cap_reinv ( fin_moh_id INTEGER NOT NULL, fin_cap_reinvest_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fin_cap_reinvest_id), FOREIGN KEY (fin_cap_reinvest_id) REFERENCES fin_capital_reinvest on delete cascade, FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_moh_cap ( fin_moh_id INTEGER NOT NULL, fin_capital_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fin_capital_id), FOREIGN KEY (fin_capital_id) REFERENCES fin_capital on delete cascade, FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_moh_acc_pay ( fin_moh_id INTEGER NOT NULL, fin_accpay_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fin_accpay_id), FOREIGN KEY (fin_accpay_id) REFERENCES fin_account_payable on delete cascade, FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_moh_rev ( fin_moh_id INTEGER NOT NULL, fin_revenue_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fin_revenue_id), FOREIGN KEY (fin_revenue_id) REFERENCES fin_revenue on delete cascade, FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_moh_exp ( fin_moh_id INTEGER NOT NULL, fin_expense_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, fin_expense_id), FOREIGN KEY (fin_expense_id) REFERENCES fin_expense on delete cascade, FOREIGN KEY (fin_moh_id)
REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_tax_types ( fin_tax_type VARCHAR2(8) NOT NULL, fin_tax_desc VARCHAR2(40) NOT NULL, PRIMARY KEY (fin_tax_type) ); CREATE TABLE fin_tax_expense ( fin_expense_id INTEGER NOT NULL, fin_tax_type VARCHAR2(8) NULL, PRIMARY KEY (fin_expense_id), FOREIGN KEY (fin_tax_type) REFERENCES fin_tax_types on delete cascade, FOREIGN KEY (fin_expense_id) REFERENCES fin_expense on delete cascade ); CREATE TABLE fin_depreciation_expense ( fin_expense_id INTEGER NOT NULL, fac_inventory_id INTEGER NULL, PRIMARY KEY (fin_expense_id), FOREIGN KEY (fac_inventory_id) REFERENCES fin_inventory on delete cascade, FOREIGN KEY (fin_expense_id) REFERENCES fin_expense on delete cascade ); CREATE TABLE svn_inventory ( svn_inventory_id INTEGER NOT NULL, timestamp DATE NOT NULL, value INTEGER NOT NULL, status VARCHAR2(8) NULL, PRIMARY KEY (svn_inventory_id) ); CREATE TABLE fin_moh_svn ( fin_moh_id INTEGER NOT NULL, svn_inventory_id INTEGER NOT NULL, PRIMARY KEY (fin_moh_id, svn_inventory_id), FOREIGN KEY (svn_inventory_id) REFERENCES svn_inventory on delete cascade, FOREIGN KEY (fin_moh_id) REFERENCES fin_money_on_hand on delete cascade ); CREATE TABLE fin_sold_item ( fin_revenue_id INTEGER NOT NULL, fac_inventory_id INTEGER NOT NULL, PRIMARY KEY (fin_revenue_id, fac_inventory_id), FOREIGN KEY (fac_inventory_id) REFERENCES fac_inventory on delete cascade, FOREIGN KEY (fin_revenue_id) REFERENCES fin_revenue on delete cascade ); CREATE TABLE fin_rev_svn ( fin_revenue_id INTEGER NOT NULL, svn_inventory_id INTEGER NOT NULL, PRIMARY KEY (fin_revenue_id, svn_inventory_id), FOREIGN KEY (svn_inventory_id) REFERENCES svn_inventory on delete cascade, FOREIGN KEY (fin_revenue_id)
REFERENCES fin_revenue on delete cascade ); CREATE TABLE fin_data_cache ( name VARCHAR(8) timestamp DATE PRIMARY KEY (name) );
NOT NULL, NOT NULL,
CREATE TABLE fin_income_cache ( timestamp DATE NOT NULL, value INTEGER NOT NULL, primary key (timestamp) );
Kemudian Data Modification Language (DML) juga dideklarasikan sebagai berikut: INSERT INTO fac_inventory values (8001,'BARBEL',sysdate,100000,5,'ACTIVE'); INSERT INTO fac_inventory values (8002,'RAKET TENIS',sysdate,325000,3,'ACTIVE'); INSERT INTO fac_inventory values (8003,'SWIRL POOL',sysdate,4500000,5,'ACTIVE'); INSERT INTO fac_inventory values (8004,'RAKET SQUASH',sysdate,250000,3,'ACTIVE'); INSERT INTO fac_inventory values (8005,'TRACK MILL',sysdate,625000,5,'ACTIVE'); INSERT INTO fac_inventory values (8006,'MAGNETIC HOOLA HOOP',sysdate,125000,3,'ACTIVE'); INSERT INTO fac_inventory values (8007,'ANTI GRAVITATION DUMBEL',sysdate,1250000,6,'ACTIVE'); INSERT INTO fac_inventory values (8008,'BOLA BASKET',sysdate,55000,2,'ACTIVE'); INSERT INTO fac_inventory values (8009,'BOLA TENIS',sysdate,45000,0.5,'ACTIVE'); INSERT values INSERT values
INTO fin_tax_types (fin_tax_type,fin_tax_desc) ('PPn','Pajak Penambahan Nilai'); INTO fin_tax_types (fin_tax_type,fin_tax_desc) ('PPh','Pajak Penghasilan');
INSERT INTO fin_tax_types (fin_tax_type,fin_tax_desc) values ('PBB','Pajak Bumi dan Bangunan'); INSERT INTO fin_tax_types (fin_tax_type,fin_tax_desc) values ('KKN','Biaya birokrasi');
Stored procedure yang merupakan script bagaimana modul lain berinteraksi dengan modul keuangan dalam hal pemasukan, penghapusan data dibuat dalam bentuk pseudocode dulu. Pseudocode dari stored-procedure adalah sebagai berikut: function fac_sell_item { if(sold_amount < 0) { ERROR } update fin_revenue update fin_sold_item update fin_money_on_hand update fin_moh_rev } function fac_buy_item_cash { if(amount < 0) {
ERROR } update fin_money_on_hand update fin_inventory update fin_moh_rev } function fac_buy_item_credit { if(amount < 0) { ERROR } update fin_account_payable update fin_inventory update fin_inv_acc_pay } function fac_buy_item_repay { update fin_account_payable update fin_money_on_hand update fin_moh_acc_pay } function mbr_income { update fin_revenue update fin_money_on_hand update fin_moh_rev } function stf_pay_salary { if(amount < 0) { ERROR } update fin_expense update fin_money_on_hand update fin_moh_exp } function svn_income { if(amount < 0) { ERROR } update fin_revenue update fin_money_on_hand update fin_moh_rev } function crs_income { if(amount < 0) { ERROR } update fin_revenue update fin_money_on_hand update fin_moh_rev } function fac_input_tax { if(tax_value < 0) { ERROR } update fin_money_on_hand update fin_expense update fin_moh_rev update fin_tax_expense } function svn_buy_souvenir { if(amount < 0) {
ERROR } update fin_money_on_hand update fin_moh_svn }
Dengan adanya pseudocode di atas, stored procedure kembali diimplementasikan menjadi: /*=============================================================== Oracle PL/SQL Stored Procedures Data manipulation of the system will be done exclusively through the use of stored procedures. This design decision is made to improve data integrity and consistency.
===============================================================*/ /************************************************************************* Used to change an employee's password. Parameters: essn The employee's SSN. oldpassword The employee's current password. newpassword The employee's new password. Return codes: 0 change password success -1 wrong password -2 Data not found */ create or replace function change_password ( essn in employee.ssn%type, oldpassword in employee.password%type, newpassword in employee.password%type ) return binary_integer as ssn_in employee.ssn%type; password_in employee.password%type; begin select ssn, password into ssn_in, password_in from employee where ssn = essn; if (password_in = oldpassword) then update employee set password = newpassword where password = oldpassword and ssn = essn; return 0; else return -1; end if; exception when no_data_found then
/* dbms_output.put_line('Data not found'); */ return (-2); end; / show errors;
/************************************************************************* Called by the front end system when an employee checks in or checks out.
Parameters: e_ssn the employee's SSN e_password the employee's password Return code 1 Check in success 2 Check out success -1 Wrong password -2 Data not found
*/ create or replace function check_in_out( e_ssn in employee.ssn%type, e_password in employee.password%type ) return binary_integer as ename_out employee.name%type; essn_out employee.ssn%type; epassword_out employee.password%type; starttime date; endtime date; status_check_in boolean; now date; nowchar char(2); cursor c1 is select emp_ssn, start_timestamp, end_timestamp from work_times where emp_ssn = e_ssn; c_rec c1%rowtype; begin now
:= SYSDATE;
--dbms_output.put_line(SYSDATE); status_check_in := true; for c1_rec in c1 loop if (c1_rec.start_timestamp is not null) and (c1_rec.end_timestamp is null) then status_check_in := false; else status_check_in := true; end if; end loop; select ssn, name, password into essn_out, ename_out, epassword_out from employee where ssn = e_ssn ; if (e_password = epassword_out) then if (status_check_in = true) then insert into work_times values (essn_out, SYSDATE, null); -- dbms_output.put_line('Check in success!!'); return (1); else update work_times set end_timestamp = SYSDATE where emp_ssn = essn_out and end_timestamp is null;
-- dbms_output.put_line('Check out success!!'); return (2);
end if; else
-- dbms_output.put_line('Wrong password'); return (-1); end if;
exception when no_data_found then
-- dbms_output.put_line('Data not found'); return (-2); end; / show errors;
/************************************************************************* Cleans up the work_times table from old data. After cleanup, the work_times table will only contain data for the current month.
*/ create or replace procedure clean_up as begin delete from work_times where to_char(end_timestamp, 'MM') != to_char(SYSDATE, 'MM') and end_timestamp is not null;
/* dbms_output.put_line('Clean up success!!'); */ end; / show errors; /*
USED TO DELETE AN EMPLOYEE */ create or replace procedure delete_emp( essn in employee.ssn%type ) as begin DELETE FROM PROJECT_ROLES WHERE EMP_SSN=ESSN; DELETE FROM WORK_TIMES WHERE EMP_SSN=ESSN; DELETE FROM EMPLOYEE WHERE SSN=ESSN; end; / show errors;
/** END Stored Procedures **/
Tahap design pada kelompok kami menghasilkan DDL, DML dan stored procedure.
IV. Implementation Phase Sebelum memasuki proses implementasi, kami menyadari bahwa sistem informasi ini harus dibagi menjadi sub- modul sesuai dengan prinsip divide and conquer. Sistem informasi keuangan ini dirasakan cukup besar cakupannya sehingga dengan cara membagi kerja antar anggota kelompok dapat meringankan beban kerja keseluruhan. Dan karena kelompok kami terdiri dari 6 orang, maka kami beranggapan bahwa semua sumber daya manusia yang tersedia di kelompok mesti dimanfaatkan dalam pengembangan proyek sistem informasi
ini. Untuk itulah, kami telah menyusun kerangka kerja kelompok beserta milestonemilestone yang harus terselesaikan pada jadwal yang telah ditetapkan. Proses pembagian kerja ini juga mengharuskan kami untuk mendefinisikan sub- modul yang akan diimplementasikan. Adapun referensi yang dipakai di dalam menentukan sub modul adalah DFD level 0 dan level 1 yang kami hasilkan pada proses analisa. Berikut adalah pembagian tugas beserta milestone dan sumber daya yang dialokasikan untuk masing- masing submodul: -------------------------------------------------------------------------------------------------------------List of milestones to be achieved at the scheduled date Milestone 0 (1 Mei 2001) ? Analysis and design are completed ? API final version ( containing name, input , output and domain ) is released ? Scheduling process ( including other modules ) is cleared ? Whitepaper ( specs docs ) is released ? Prototype is achieved ? Testing process is partially completed ? Manual and documentations is partially completed Milestone 1 (8 Mei 2001) ? Stored procedure is completed ? Database connection module is completed ? Program skeletons is achieved ? Balance sheet, journal and profit/loss report are completed ? High level authorization is completed ? Testing process is partially completed ? Manual and documentations is partially completed Milestone 2 (15 Mei 2001) ? Capital changes report , prive input , new investment input and taxes input are completed ? Testing process is partially completed ? Manual and documentations is partially completed Milestone 3 (22 Mei 2001) ? Depreciation input , appreciation input , profit prediction and charts ? Help session is completed ? Testing process is completed ? Manual and documentations is completed
Job allocation to each milestone Milestone 1 Stored procedures: Database connection module: Program skeletons: Balance sheet, journal and profit/loss report sub modules: Manual & documentation: Milestone 2 : Prive and new investment input sub modules: Capital changes sub modules: Taxes input sub modules: Manual & documentation: Milestone 3 : Profit prediction:
Human Resources sen199 & fred199 sas199 juli199 & tung199 juli199 & jute199 jute199 sen199 & fred199 juli199 & jute199 sas199 & tung199 jute199 sen199 & fred199
Appreciation input: Depreciation input: Charts: Help: Manual & documentations:
sas199 tung199 juli199 & jute199 jute199 jute199
-------------------------------------------------------------------------------------------------------------------------------------
Dengan adanya kerangka kerja di atas, masing- masing anggota kelompok berkewajiban untuk menginplementasikan submodul yang telah dialokasikan. Pembagian kerja dilakukan secara demokratis artinya tidak ada anggota kelompok yang merasa dirugikan dalam hal pembagian sub- modul ini. Mereka yang merasa dapat mengerjakan suatu sub- modul dapat langsung “mengambil” submodul tersebut. Berikut adalah cuplikan code algoritma yang dipakai pada sistem informasi keuangan Sport Club: --------------------------------------------------------------------------------------------------------------‘ Modul Neraca Keuangan Option Explicit Dim report As String Dim rsReport As Recordset Dim myYear Dim thisYear Dim cmd As New ADODB.Command Dim rs As ADODB.Recordset Dim laba As Long Private Sub CmdProfitLosesRefresh_Click() thisYear = ListYear.Text If (lbUpdate.Caption = "") Then cmdUpdate.Enabled = True ElseIf (Right(lbUpdate.Caption, 4) >= Val(thisYear)) Then cmdUpdate.Enabled = True Else: cmdUpdate.Enabled = False End If createReport 'Download blank page WebBrowser1.Navigate2 "about:blank" End Sub Private Sub cmdUpdate_Click() On Error GoTo handle cmd.CommandText = "insert into fin_data_cache values ('LABA',to_date('" + thisYear + "','yyyy'))" cmd.Execute handle: If Err.Number = -2147217900 Then cmd.CommandText = "update fin_data_cache set timestamp = to_date('" + thisYear + "','yyyy') where name = 'LABA'" cmd.Execute End If lbUpdate.Caption = thisYear cmdUpdate.Enabled = False End Sub Private Sub WebBrowser1_DocumentComplete(ByVal pDisp As Object, URL As Variant) WebBrowser1.document.body.innerHTML = report End Sub Private Sub Form_Load() Set cmd.ActiveConnection = dbc
cmd.CommandType = adCmdText cmd.CommandText = "SELECT to_char(trunc(timestamp),'yyyy') year FROM fin_data_cache where name = 'LABA'" Set rs = cmd.Execute Dim myDate myDate = Now Dim year myYear = DatePart("yyyy", myDate) year = myYear If Not (rs.EOF) Then Dim temp temp = rs.Fields("year").Value thisYear = Right(temp, 4) lbUpdate.Caption = temp If (Val(myYear) >= Val(thisYear)) Then cmdUpdate.Enabled = True End If Else thisYear = Str(myYear) thisYear = Right(thisYear, 4) End If Dim myYear1 myYear1 = myYear Dim ctr For ctr = year To 2001 Step -1 ListYear.AddItem (myYear1) myYear1 = myYear1 - 1 Next ctr ListYear.ListIndex = myYear - 2001 rs.Close createReport 'Download blank page WebBrowser1.Navigate2 "about:blank" End Sub Public Sub createReport() Set cmd.ActiveConnection = dbc cmd.CommandType = adCmdText report = "
Laporan Rugi Laba | | |
" report = report + " | Debit | Kredit |
" report = report + " Pendapatan |
" laba = 0 cmd.CommandText = "SELECT sum(value) total FROM fin_revenue where to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and upper(source_table) = 'FAC_SELL_ITEM'" Set rs = cmd.Execute report = report + " Pendapatan non operasional | " If Not IsNull(rs.Fields("total").Value) Then laba = laba + rs.Fields("total").Value report = report + " | " + Str(rs.Fields("total")) + " |
" Else report = report + " | 0 | " End If cmd.CommandText = "SELECT sum(value) total FROM fin_revenue where to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and (upper(source_table) = 'MBR_PAYS' or upper(source_table) = 'NMB_PAYS')" Set rs = cmd.Execute report = report + " Pendapatan
operasional | " If Not IsNull(rs.Fields("total").Value) Then laba = laba + rs.Fields("total").Value report = report + " | " + Str(rs.Fields("total")) + " |
" Else report = report + " | 0 | " End If
cmd.CommandText = "SELECT sum(value) total FROM fin_revenue where to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and upper(source_table) = 'SVN_SALES'" Set rs = cmd.Execute report = report + " Pendapatan souvenir | " If Not IsNull(rs.Fields("total").Value) Then laba = laba + rs.Fields("total").Value report = report + " | " + Str(rs.Fields("total")) + " |
" Else report = report + " | 0 | " End If report = report + " |
" report = report + " Beban |
" cmd.CommandText = "SELECT sum(value) total FROM fin_expense where to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and upper(source_table) = 'FIN_DEPRECIATION_EXPENSE'" Set rs = cmd.Execute report = report + " Beban depresiasi | " If Not IsNull(rs.Fields("total").Value) Then laba = laba - rs.Fields("total").Value report = report + "" + Str(rs.Fields("total")) + " | |
" Else report = report + "0 | | " End If cmd.CommandText = "SELECT sum(value) total FROM fin_expense where to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and upper(source_table) = 'STF_PAYS'" Set rs = cmd.Execute report = report + " Beban gaji | " If Not IsNull(rs.Fields("total").Value) Then laba = laba - rs.Fields("total").Value report = report + "" + Str(rs.Fields("total")) + " | |
" Else report = report + "0 | | " End If cmd.CommandText = "SELECT sum(value) total FROM fin_expense where to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and upper(source_table) = 'FIN_TAX_EXPENSE'" Set rs = cmd.Execute report = report + " Beban pajak | " If Not IsNull(rs.Fields("total").Value) Then laba = laba - rs.Fields("total").Value report = report + "" + Str(rs.Fields("total")) + " | |
" Else report = report + "0 | | " End If
cmd.CommandText = "SELECT sum(value) total FROM fin_expense where to_char(trunc(timestamp),'yyyy') = '" + thisYear + "' and upper(source_table) = 'FAC_EQUIPMENT'" Set rs = cmd.Execute report = report + " Beban perlengkapan | " If Not IsNull(rs.Fields("total").Value) Then laba = laba - rs.Fields("total").Value report = report + "" + Str(rs.Fields("total")) + " | |
" Else report = report + "0 | | " End If On Error GoTo handle cmd.CommandText = "insert into fin_income_cache values (to_date('" + thisYear + "','yyyy')," + Str(laba) + ")" Set rs = cmd.Execute handle: If Err.Number = -2147217900 Then cmd.CommandText = "update fin_income_cache set value = " + Str(laba) + " where timestamp = (to_date('" + thisYear + "','yyyy'))" Set rs = cmd.Execute End If report = report + " |
" report = report + " Laba | | " + Str(laba) + " |
" End Sub
--------------------------------------------------------------------------------------------------------------Berikut adalah cuplikan manual operasional sistem informasi Sport Club ---------------------------------------------------------------------------------------------------------------
Neraca Keuangan Neraca keuangan yang ditampilkan dapat dilihat pada kedua browser yang tersedia pada form neraca keuangan. Browser di sebelah kiri menampilkan data akuntansi aktiva dan browser di sebelah kanan menampilkan data akuntansi passiva. Aktiva terbagi 2 bagian yaitu aktiva lancar berupa kas dan aktiva tetap berupa gedung, peralatan dan tanah. Yang termasuk data akuntansi passiva adalah hutang dan modal. Jumlah nilai yang berada di sebelah debit dan kredit haruslah selalu sama. Informasi keuangan yang ditampilkan pada neraca ini adalah berdasarkan pada periode tahun tertentu, jadi pengguna dapat menampilkan neraca keuangan tahun yang sebelumnya. Neraca keuangan yang ditampilkan pada saat form ini ditampilkan adalah neraca keuangan tahun sekarang. Cara Penggunaan
1. Setelah menekan tombol "Neraca Keuangan" pada form Utama, maka form Neraca Keuangan akan menampilkan neraca keuangan pada browser yang tersedia.
2. Untuk menampilkan neraca keuangan yang pada tahun yang lampau, isi tahun yang bersesuaian yang terdapat di sebelah label "Periode" pada form 3. Tekan tombol "Tampilkan" untuk melihat neraca keuangan yang bersesuai dengan tahun yang dipilih pada langkah 2
----------------------------------------------------------------------------------------------------------------
V. Testing Phase Testing terhadap sistem informasi Sport Club dilakukan oleh dua orang, yaitu Hansen (sen199) dan Julius Liman (juli199) selama satu hari. Tester melakukan black-box testing, yaitu berfokus pada fungsi dari setiap modul. Black-box testing ini bertujuan untuk menemukan error pada beberapa hal berikut ini: ? Fungsi yang salah / hilang. ? Kesalahan interface. ? Kesalahan pada data structure. ? Kesalahan pada saat run-time. ? Kesalahan pada inisialisasi dan terminasi program. Metode black-box testing yang digunakan adalah Equivalence Partitioning, yaitu metoda yang membagi domain input data dari suatu program menjadi dua, valid dan invalid. Pendekatan yang dilakukan dalam black box testing adalah sebagai berikut: ? Jika suatu kondisi input memerlukan suatu range tertentu, satu valid dan dua invalid set data digunakan. ? Jika suatu kondisi input memerlukan suatu nilai tertentu, satu valid dan dua invalid set data digunakan. ? Jika suatu kondisi input memerlukan suatu anggota dari set tertentu, satu valid dan satu invalid set data digunakan. ? Jika kondisi inputnya boolean, satu valid dan satu invalid set data digunakan. Kami juga melakukan white-box testing, yaitu melakukan testing pada fungsi internal, mengecek semua keputusan logical pada sisi true dan false, menjala nkan semua loop pada batasannya dan validasi struktur data internal. Setelah dilakukan integrasi dengan kelompok lain, dilakukan integration testing. Karena pada integrasi ini yang dilakukan hanya sebatas integrasi pada database maka tidak dilakukan testing lagi pada setiap modul. Jadi hanya dilakukan validasi pada struktur data internal, yaitu melakukan semua operasi yang berhubungan dengan database dengan membuat sample data dan juga melakukan validasi pada setiap operasi yang mengupdate data base.
Related Documents