Managing Parents' Information and School Fees Transactions

The Parents Information and Fees Transaction Management.

Suggestions and Recommendations

It is very common that programmers will not tell you much about the inner design arrangements of their systems.  At SchoolWrite, we do believe that when you understand that detail, it helps you solve many issues by yourself and earn the best out of the product.  This post is intended to guide you set up your Parents School Fees area in a way that yields the best for you.

SchoolWrite (SW) presupposes that it is the parent paying the dues to the school.  That known, everything concerning fees is under the parents menu and in the School Fees Menu item.  The other areas under the parents menu are for bio data and communications e.g. parents listings, standard letters (circulars) and SMS broadcasts, etc.

Every Parent on the database MUST have a code that is uniquely identifying that record and that code must be keyed on the student attached to that parent.  If more than one learners are to share the same parent, then they should all share that one parent code.  We usually recommend to use the student number as the parent code for simplicity.  When the billing is done, when credits are adjusted, or when fees receipts are made (fees paid) from a particular student/parent, the transactions are all posted against that parent code, and they are seen on that parent's fees statement.  In cases of one parent having more than learner attached, if their dates of birth are well entered, the name of the oldest learner (and class/stream) will appear on the statement, so it is given to that one to deliver home.

Please NOTE that when a student is deleted out of SW (probably because there was duplication, etc.), the parent side of that student is still there at this moment.  The same thing happens when a student leaves school or graduates. Here is where we need to strongly shout that; never put a new student on SW and use a number for a student you have deleted or graduated unless if you are very sure there are no transactions on that code because that learner will automatically inherit the fees transactions found on that code (if they exist).  It is common mistake for users to think that when they have deleted a student, the parent has also been removed.  Wrong!  This parent record stays and helps the business office to locate if someone went with a debt, when they come back to pick their credentials/certificates/testimonials and/or pass slips.  The learner will be in the past students area, but the fees transactions will still be seen under parents on the same code.

SW allows discounts and subsidies.  They can be as a percentage, or as a fixed amount off the billed amount.  School Bursars usually forget to set this and go into a hustle of adjusting amounts for every learner who doesn't pay like the others.

Setting the flag marked 'Billed automatically' to 'N' excludes that parent from being billed at all.  In case a fee has to apply to that parent, it would have to be entered through 'charges & credit adjustments'.

The listing on grid shown indicates the transactions as they have been occurring and the red lines show transactions that have never been printed on any statement.

This brings us to what we call Condensing Amounts.  As parents keep paying, transactions accumulate on their ledgers/statement.  The growth depends on the number of transactions made for that parent.  Some might pay in many instalments and their statements grow much faster.  We recommend that at the end of the year, statements are printed and filed, a backup is made and this process be invoked.  It sums up all the parent's transactions and if a parent has a non-zero balance, it comes back as one transaction with a description 'BALANCE FORWARD'.  Then a new journey starts again.  If you do not print the statements, those lines in red color will not be condensed.  If a parent had Zero balance, the statement will be empty.  If there's no active student attached to that parent, that record is now able to leave the database.  You can delete one-by-one, or use a menu to delete all the parents that qualify to.

When we are printing statements, we can choose statements of students having a balance above a nominated value (brown mark), or all statements for a particular class/stream (purple mark).  There're other variables to nominate if needed.  This is where we can as well create the statements and email them to the parents' emails as .pdf attachments (green mark).

The process of previewing (or printing) will create the .pdf and save them into the nominated folder/path, and when the button is selected/clicked, SW will send the emails with those files as attachments to the associated addresses.  The text that goes in the email body is set by you in one of the letter templates you created through 'Communicate with parents'.  SW will allow you to select that file when you click 'Send emails'.  You could have noticed that SW has a mail merger where one letter is prepared and the software puts on addresses and salutations, etc. according to the parameters used vis a vis the data against the students/parents.  Substitution codes for fees balances may also be used.

Selective printouts for fees defaulters may be made and others may be tailored to meet your exact needs.  Some users need defaulters list with no amounts shown so that teachers can help organize those learners to meet the bursar, because the amounts will be confidential between the learners/parents and the business office.  Lists showing Names, Class/Stream, Total Bill, Amount Paid  and  Balance are also a common request.  Users can request for various layouts as their need may be.  Request can come in any time even after running SW for a long time, our programming house is ready to help you achieve what the information need requires.

SMS broadcasts have too been a great tool in improving school cashflows.  When phone contacts are entered into SW, those that are marked to receive school communications will receive the messages.  One message is set as the template with substitution parameters for e.g. student's given name, amount outstanding, parent code, payment code may all be addressed.  When that template is used, the mail merger will create an SMS message string for each telephone line marked to receive.  The merger will substitute a standing amount for each parent in the list i.e. every parent will receive an amount valid to their children.  Servers are available where you can also upload that message file and the message gets broadcasted on a day and time you nominate.  This is useful at times when you want the message to go but you will not be in office to administer it e.g. you want a message to go on a public holiday.

The interface that downloads payments made through SchoolPay is also available with its advantages.  Bursars do not have to enter these records manually.  You need to connect us with the person who manages your SchoolPay issues so we can request from them what you need to have this service implemented for your school.  For a number of schools, we have developed small web interfaces that have helped schools to collect current contact details and payment codes so that the parents help do the data entry themselves to minimize mistakes.  They have entered their own phone numbers, email addresses, SchPay codes, etc.  We would write a small program to read that data from the cloud into SchoolWrite and the school starts at a higher note.

We need to say it has been a nice moment sharing with you on a journey to better information management.  We have a number of blogs that address various issues raised by users and those interested in better records even when they do not use SchoolWrite.  Please feel free to email/WhatsApp in with any inquiry and we shall put it to our technical grid to see how best you benefit from our developments.

Thank you!

Samuel Gitta

SchoolWrite

+256 772 430202 WhatsApp

+256 752 726835

info@schoolwrite.co.ug