red1.org

[Gan MH]

I have uploaded some html pages (screen designs) at: http://www.red1.org/barn/Cybernetics/billing_views.rar

There are two (2) main folders consist of the screen designs for two (2) different user roles:
1. Screen designs for Khairin
2. Screen designs for Staffs that handle Pre-Registration during registration day.

Khairin's View (khairin_view folder)
1. Default Page (index.htm)
2. Pre-Registration (index.htm -> pre-registration.htm -> pre-registration_edit.htm) // ("details" button -> popup program_details.htm)
3. Register Pre-Registration Students (index.htm -> permanent_registration_display.htm -> permanent_registration.htm)
4. Student Invoice Batch (index.htm)
5. Student Invoice Individual (student_invoice_individual.htm)
6. Invoice to Sponsors (invoice_to_sponsor.htm)

Pre-Registration Staffs' View (pre-registration_staff_view folder)
1. Default Page (index.htm)
2. Pre-Registration (index.htm -> pre-registration.htm -> pre-registration_edit.htm) // ("details" button -> popup program_details.htm)

I will proceed with screen designs for En Ibrahim which include of:
1. Fee Structure
2. Student Invoice (Batch)
3. Student Invoice (Individual)
4. Invoice to Sponsors
5. Batch Payment
6. Individual Payment
7. Reports

[Gan MH]

I have uploaded the second part of screen designs (html pages) at: http://www.red1.org/barn/Cybernetics/billing_views2.rar

Again, there are two (2) folders consist of the screen designs for two (2) different user roles:
1. Screen designs for En Ibrahim
2. Screen designs for Staffs that handle Payment

En Ibrahim's View (ibrahim_view folder)
1. Default Page (index.htm)
2. Fee Structure (index.htm) // ("Report" button -> popup fee_structure_report.htm)
3. Payment and Receipt (index.htm -> individual_payment.htm)
4. Batch Payment (index.htm -> batch_payment.htm) // ("details" button -> popup program_details.htm) and ("Student List" button -> popup student_list.htm)
5. Batch Invoice (invoice_student_batch.htm)
6. Student Invoice (invoice_student_individual.htm)
7. Invoice to Sponsors (invoice_to_sponsor.htm)
8. Reports (reports1.htm & reports2.htm)

Payment Staffs' View (payment_staff_view folder)
1. Default Page (index.htm)
2. Payment and Receipt (index.htm -> individual_payment.htm)
3. Batch Payment (index.htm -> batch_payment.htm) // ("details" button -> popup program_details.htm) and ("Student List" button -> popup student_list.htm)

[red1]

This shuld be under a separate topic as we are reengineering the look and feel.
Anyway, next shuld be the vm tags for placeholders by the java velocity context names.
An overall index of all the screens accordiing to the operations will be good. The hyperlinks has to connect between the various screens so that a very quick preview can be done.
This is all very nice for a high level zoom in look from the users' perspective.

[red1]

Last week i have done FIFO in the payment window and have uploaded to CVS. It requires the addition of a new field OriAmt (OriginalAmt) in the StudentBilling table.

The next thing i need to get from Sam is how to use the VM to update values that are supposed to be there first, as we are using consistent VMs. Maybe use 2-step display.

Then we decided to do a major revamp of look and feel. Awaiting for Sam to architect some framework, and assign me what portion to do.

Gan or Sam can also get me to resolve any bugs.

[Gan MH]

I have discussed with Sam and he is ok with those screen designs. However, he needs to do some modifications to the framework designs in order for the system to accept those new designs. The Estimated Accomplised Time is next Tuesday where we shall be able to demo by then.

[Gan MH]

The new screen designs are made up of four (4) panels: TopLeft Panel, TopRight Panel, Button Panel and Bottom Panel.

I foresee a potential problem in this kind of design. We might hit problem when En Ibrahim wants to add new screen to his view (add new button to the Button Panel). I think this can be solved by:

1. Change those buttons into pictures so that we can control the picture size better
2. Remove the Button Panel and use the existing TAB Navigation instead

I need to know will changes in (1) and (2) make any difference to Portal framework design. Please feedback.

[Gan MH]

I have made some changes to the screen designs especially on the Batch Payment part. Please download it at: http://www.red1.org/barn/Cybernetics/billing_views3.rar

[red1]

To remind Gan and Sam that the Payment & Receipt Screen columns for paying shuldn't be BILLED PAID BALANCE but

BALANCE PAYING

Two columns only. This is the FIFO module that i have done to fit to these 2 cols.

The BILLED shuld be viewed under the Account Statement Module.

BALANCE means what is outstanding, so that PAYING will just show what is been paid now when the figure is entered for PAYMENT. BALANCE will change once PAYING changes. i.e.

previous:
BALANCE (1000) PAYING (0)

after
BALANCE (300) PAYING (700)

so from here the User easily and intuitively sees that the 1000 becomes 300 cos she puts in 700. The next time she logins again, the
BALANCE (300) PAYING (0)
then she pays all becomes
BALANCE (0) PAYING (300)

Remember that originally the client even dont want to see balance or billed. Just pay and print. Later check the statement.

En Ibrahim is ok with the scren design for Payment & Receipt Screen, so I think we don't change anything at the moment. We shall change the word Balance to Account Balance only. - Gan

Gan, I tried to dry run it on paper and see. To see what happens during the next progress payment. What will show up for BILLED, PAID, and BALANCE?
It seems all 3 can become 'stuck' and unusable. Only Balance is useful as a latest status figure. But where then to put in the new PAYING amount? cannot be in BILLED (its always showing ori owing) and also not in PAID (your previous paid and not this paying). Thus u then end up with a new progress column. Remember our Shifa company invoice where we do 3 columns but they are not same cos they are PAYABLE, CURRENT, PAID and its more of payment advice. Let's resolve this business scenario first before we change the coding.

[Gan MH]

Here I list down all inputs from En Ibrahim and En Khairin during our discussion dated 25th-August-2005.

1. Enable Sort by Metric Number in Register Pre-Registration Student window

2. Create a Remark Field in 1) Pre-Registration window and 2) Payment and Receipt window. The Remark Field is to keep track of payment info such as credit card no., bank draft no. cheque no., etc.

3. There are two (2) important things in Batch Invoicing:
i) DO NOT include non-active student (withdraw, study leave, etc)
ii) ALWAYS invoice to the next study period which has not been invoiced

4. There are changes in screen designs for Batch Payment window and Reports window. I have also clarified the Account Statement window with En Ibrahim. I shall post all new screen designs in next round.

5. En Ibrahim asked to change screen designs for Payment Staff’s View and Pre-Registration Staff’s View back to single-panel view. Besides, he requested to lock these two (2) views to full screen view and hide all unnecessary browser buttons.

6. Use the same invoice number for Student Invoice and Sponsor Invoice. i.e. Invoice No. for Student A Semester 1 is INV0001, Invoice No. to Sponsor for Student A Semester 1 must also be INV0001.

7. Use Program Abbrev. instead of Program Code in all Bursary Module views.

8. For reporting purposes, the system must keep track of whether 1) an invoice is issued to student or sponsor, 2) an payment receipt is from student or sponsor.

9. We will introduce two (2) new terms:
i) Account Balance - 1) Payment and Receipt window 2) Account Statement window
ii) Sponsor Balance - Batch Payment window

10. The Account Statement can be similar to Maybank2u Statement whereby there is indication for each transaction. i.e. payment by MARA: RM1000.00, Payment by cheque (cheque no.) RM1500.00.

11. There will be six (6) basic reports at the moment:
i) Details of Invoiced Amount by Student
ii) Details of Receipt Amount by Student
iii) Details of Outstanding Amount by Student
iv) Details of Invoiced Amount by Sponsor
v) Details of Receipt Amount by Sponsor
vi) Details of Outstanding Amount by Sponsor

12. There are total of six (6) Print Format designs in Bursary Module:
i) Invoice
ii) Receipt
iii) Statement
iv) MARA Invoice
v) PTPTN Invoice
vi) Other Invoice

We are given permission to design Print Format (i), (ii) and (iii). These Print Formats should consist of the following:

Header
1) Logo
2) Company Name & Number 3) JPW Number
4) Title: Receipt / Invoice / Statement
5) Number of Receipt / Invoice / Statement

Content – Student Details
6) Name
7) Metric Number
Program
9) Period of Study (Semester)
10) Amount / Transactions
11) Payment Mode
12) Date

MARA Invoice, PTPTN Invoice and Other Invoice have certain standards to follow. I will ask for sample invoices from En Ibrahim/En Khairin.

[Gan MH]

Please download the latest screen designs at: http://www.red1.org/barn/Cybernetics/billing_views4.rar The latest package consists of all changes as per En Ibrahim and En Khairin inputs.

The followings have been changed in the new screen designs:

1. Payment and Receipt window
2. Batch Payment window
3. Report1 window
4. Report2 window
5. Account Statement window (new)
6. Pre-Registration window
7. Payment Staff’s view
8. Pre-Registration Staff’s view

[Gan MH]

Continue from previous post (http://red1.org/forum/viewtopic.php?p=2766#2766)

13. Allow Khairin to define the next running metric number.

14. Allow Pre-Registration window to accept zero deposit paid.

15. At Program Structure window, sort subject (in defined program structure) by code.

16. At Student Enrolment window, add algorithm to determine DOB and Gender from NIRC. (this can save up a lot of their time)

17. At Student Enrolment window, add new TAB to show Student Academic Background (data is in the given database).

18. At Student Enrolment window, add new fields for student data:- (data is in the given database).
a. Mobile
b. Place of Birth
c. Marital Status
d. Religion
e. Race
f. Nationality
g. Name of Parents/Guardian

19. At Student Status window, add new statuses:
a. Withdraw
b. Dropped Out
c. Graduated

###################

PANDUAN KOD

KOD NEGERI
A – PERAK
B – SELANGOR
C – PAHANG
D – KELANTAN
E – THAILAND
I – INDONESIA
J – JOHOR
K – KEDAH
L – LAIN-LAIN
M – MELAKA
N – N SEMBILAN
P – P PINANG
R – PERLIS
S – SINGAPURA
T – TERENGGANU
U – BRUNEI
V – WP LABUAN
W - WP K LUMPUR
X- SABAH
Y – SARAWAK
Z – WP PUTRAJAYA

KOD TARAF PERKAHWINAN
B – BUJANG
K – KAHWIN
D – DUDA
J – JANDA

KOD AGAMA
I – ISLAM
B – BUDDHA
H – HINDU
L – LAIN-LAIN

KOD BANGSA
M – MELAYU
C- CINA
I – INDIA
H – BUMIPUTRA SABAH
K – BUMIPUTRA SARAWAK
A – ORANG ASLI SEMENANJUNG
L – LAIN-LAIN

KOD WARGANEGARA
I – INDONESIA
L – LAIN-LAIN
M – MALAYSIA
P – PENDUDUK BERMASTAUTIN DI MALAYSIA
S – SINGAPURA
U – BRUNEI

[red1]

http://red1.org/repository/PaymentRED1.GIF
(login/pass) red1org/theredone

This is payment so far. Printing receipt is next.
During Calculate, the PaymentMode is enabled, after confirming, its disabled. Calculate button will be disabled too when confirmed(not yet). A Delete option will be included if Gan and client thinks its not confusing to have in one page.

Do you mean delete button for existing receipt? (delete button should be disabled for Payment Staff view). It should be ok as long as the real development does not vary too much from the screen designs, since those screen already been agreed and approved by both Ibrahim and Khairin. - Gan
I agree. No delete here, dangerous for users, also i have to follow your design finally - red1

Already CVS.

Changes to tables:

Alter student_receipt;
add s_invoice_id varchar(50);
add payment_mode varchar(50);

Alter student_payment;
add owing float(12);
add paying float(12); - sorry, no need! - red1

[Gan MH]

aheee79: hows ur registration day on the system?
kihon73: only 8 students registered...
aheee79: but did u guys implemetn it on the new system?
kihon73: sort of....
aheee79: how is zaimi side?
kihon73: coz i just found out that the pc at the bursary counters have no physical network connection...
kihon73: so our technicians are on to that today..
kihon73: but pre-registration module works fine
kihon73: and zaimi have done some fee setup for 0512 intake

aheee79: wat is our plan for old student?
kihon73: in what sense? bursary or academic?
aheee79: both
aheee79: academic is almost migrated there
aheee79: wat about bursary info?
kihon73: bursary will prepare a masterlist in excel
kihon73: they'll choose a suitable date nad summarize each student's balance at that particular date
kihon73: thay hope that any transaction after that date can be handled by the new system...
kihon73: any inquiry prior to that have to refer to the old one....
kihon73: i think they're targeting 3 Jan 2006
kihon73: that's when invoicing for new semester commence
aheee79: how bout old transaction for existing student? do they plan to "migrate" it into new system?
aheee79: so that the new system will not be able to trace the student statement
kihon73: i'm not sure if they can produce a full record of past transactions in the very near future....
kihon73: but thay can give each student's current balance....
kihon73: if thay gonna give any detail transaction they will give it batch by batch...
kihon73: from newest to oldest....
kihon73: 0512, 0511, 0510, 0509, etc...
aheee79: that is the best solutions at the moment
kihon73: and maybe u all can give a predefined format for the bursary of important data fields so that record of transactions can easily be migrated...

[Gan MH]

Below are feedback from En Zaimi of Bursary Department on Bursary Module over the 1-week system test run:

1. Jadual yuran pengajian perlu dilebihkan sehingga 9 semester (bukan setakat 8 semester). // More semester can easily be added on En Khairin side by using the Study Period Setup Module

2. Setiap Payment & Receipt tiada daily report. // I have activated En Zaimi's Bursary Reporting Module under report section. Payment & Receipt daily report is available by selecting report type "DETAILS OF RECEIPT AMOUNT" and identifying the required start date and end date.

3. No. Matrik & Nama pelajar sahaja. Lebih bagus masukkan sekali Program (DPP, BIT) dan Semester Sekarang. // DONE. Red1 or Sam, please create and replace $!studentInfo.program_code with $!studentInfo.program_abbrev.

4. Sistem hanya menolak bayaran yuran mengikut jumlah invoices sahaja menjadi masalah sekiranya student itu bayar lebih.
Contoh:
RM2500.00 (invoice fee)
RM3000.00 (dibayar oleh student atau sponsor)
Dalam system hanya keluarkan resit RM2500.00 sahaja. Tiada transaksi lebihan wang yang ditunjukkan. // DONE by adding "overpay" in Fee_Program table

5. Tambah report mode // Available under Bursary Report Module under report section
- Baki untuk Pelajar - available
- Ikut Sponsor - to be added
- Ikut Balance - available

6. Dalam Payment and Receipt, description untuk Semester kena dinyatakan // This is set in the Fee Structure Setup Module - "DESCRIPTIONS"
Contoh:
Tuition Fee “Semester 1”
Tuition Fee “Semester 2”

7. Masalah sekiranya student nak semak jumlah hutang. // This information is easily obtained in Student Statement of Account Module placed under the report section,

8. Tiada jumlah besar hutang setiap pelajar. // Same as item (7) above

[red1]

Now Payment module can allow Cancellation of Receipt which deactivates and not remove any receipt at all from the system.
This is so that audit integrity is always possible. When cancel is done, the system no longer uses that receipt and its lines for any calculation.

Code and VMs changes are CVSed.

Later we can do a separate VM for managers only to Cancel receipts. And another program to inspect only cancelled receipts.

[Gan MH]

I had again gone tru the entire Bursary Module. Below are some of my comments:

1. To activate the receipt cancelation, we need to add "cancel" field in "student_receipt_detail" table. // I'll will add this in their live db during next installation.

2. Cannot create new invoice(s) in mecca.sis.billing.StudentInvoiceGenerateModule

3. For batch invoice, I think we shall allow user to select study session just like how we did it in sponsor invoice.

4. The running invoice number could become a problem in future. At the moment, the system creates new invoice (invoice number) during re-generation, this might end up with a lot of redundant invoices.

5. Need to change in db description: OVERPAY - TO REFUND to OVERPAY BALANCE // I'll change the overpay description in their live db during next visit.

6. How come Sponsor Payment overwrites all student payment of same receipt?