Trouble creating a logical model for a simple school cashier environment.

I have to create a system design for a cashier system. Most of the transactions would be payments for fees in a student account.

Fees like Tuition, Books, Enrollment Fees. The problem with these fees are their special characteristics like Tuition fees being staggered in MONTHLY itemization (if that's a correct term), Books can also be staggered but payable throughout a year without itemization, and Enrollment Fees which consist of the Reg Fee and the Misc Fee (which is broken down into a bunch of items) both of these Enrollment Fees required for payed during enrollment. Other fees would be just simple fees, and some other special ones are to be payed by students who've succeeded to a certain year level like Prom Fees for 3rd & 4th year students.
The thing is they need to formatted and outputted to a Student Ledger and of course an Official Receipt.

This "subsystem" is the last part of an amateur School Management System I have to design as the "System Analyst" for the team. Other subsystems are Library, Registrar, Admission.
Yes, I am a student and this is our Finals requirement.
Accounting system design I found is in such a whole new level.
Fortunately, our scope for this one is according to our adviser "easy and simple", using terms like "only debit and credit". Specifically, our scope doesn't include more complicated accounting. Only to a couple of reporting--Student Ledger and Official Receipt generation--and handling student-to-school transaction processes. But despite this "simplicity" I am a noob after all.

There's a bit more explanation but I hate to repel people would could potentially help me with a much longer wall of text than I have now.

Currently I'm stuck trying to create an ERD for this system. I'm considering flexibility of the fees, and formatting the output in the ledger and OR.

Forgive this noobishness, everyone.
I've tried my best with a 2 month deadline and there's only 1 week left, so I really need help. These accounting stuff is all that's in the way of me passing this subject.

Thank you very much.

Does the system actually have function in a real world environment? ie: is it actually going to be used for real accounting?

If not (which I hope is the case for your sake), then I think you're over-thinking this project. Make some executive decisions about how the system should work. As long as you still meet the given constraints, try to make decisions that simplify the system. If the system isn't going to be used for real, then (a) it's not going to be tested very heavily and (b) nobody else has detailed expectations for how the system should work.

For example, you say:

Does your system really need to track and enforce the fact that only 3rd or 4th year students can pay a Prom Fee? If there are no specific requirements for this, make the executive decision that it does not. Why would a 1st or 2nd year student attempt to pay a fee that isn't relevant to them anyway? However, if there is a specific requirement to have this be enforced by the system, then obviously you shouldn't make a decision to not do it.


Formatting of output should not be a consideration for a database design. Start by making a list of the basic entities that your system will need; people, fees, transactions, etc. Then consider the relationships between those basic entities. Finally, consider the properties or capabilities that each entity needs to have; ie: fees can be itemized, people can have a year, transactions can be credit or debit, etc. Don't even worry about diagramming it yet, just get your list ready first. Post that here or in the database design forum and people can help you tweak it. Right now you haven't really provided enough information for anyone to go into too many specifics (and most people won't do that anyway unless you show an attempt).

This kinda of makes me feel bad for the reason that it makes a lot of sense, that it reinforces my thought that our "adviser" is stupid for making us expect that, yes, it will implemented to an actual school. Please, don't bomb me for this, I've honestly been bummed for a long time now at how unrealistic our instructor is. I mean, he was there when we did initial data gathering meeting WITH the "client".
We do have a scope detailed enough, gradually refined through about 1 month with regular panel consultation schedules.


Thanks for confirming.
This is actually relevant, sorry for the real lack of information, but I was talking about some fees that need to be automatically debited to the student categories who are required when the time comes. I don't know how to prepare the logical design for this flexibility requirement.


Thanks a lot.
I actually already have a bunch of drafts here which I didn't want to post just because I was so ambivalent with them.

But here with my recent progress, I decided to create a table/entity FEES which would contain all fees that they would debit the student with attributes that would help controlling their properties and monitoring them possible.

Student Account
ID (PK)
Student ID (FK)
Enrollee ID (FK)

Student Account Fees
ID (PK)
Fee ID (FK)
Credit

Fees
ID (PK)
Desc
Charge Amount

Fees Template
ID (PK)
Fee ID (FK)

Transaction
ID (PK)
OR Number
Mode of Payment
Date
Debit
Credit
Balance

Particulars
ID (PK)
Transaction ID (FK)
Fee ID (FK)

Actually i too have the same problem and you have given me a good idea and cleared my doubts .