#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2012
    Posts
    4
    Rep Power
    0

    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.
    Last edited by onixsanecra; March 11th, 2013 at 01:41 AM. Reason: a little bit more information
  2. #2
  3. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,317
    Rep Power
    7170
    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:
    payed by students who've succeeded to a certain year level like Prom Fees for 3rd & 4th year students
    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.

    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.
    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).
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Oct 2012
    Posts
    4
    Rep Power
    0
    Originally Posted by E-Oreo
    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.
    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.

    Originally Posted by E-Oreo
    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.
    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.

    Originally Posted by E-Oreo
    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).
    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)
  6. #4
  7. No Profile Picture
    Banned
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2013
    Location
    New York
    Posts
    28
    Rep Power
    0
    Originally Posted by onixsanecra
    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 .

IMN logo majestic logo threadwatch logo seochat tools logo