Isn't School fee feature a duplication of sales module

Maybe I am missing out something, but I think fee feature in school can be accomplished with the sales module? An invoice could be generated for each student, fee category being an item. What is the motivation a separate payment feature?

1 Like

Student is a separate party type in ERPNext and outstanding dues, concessions etc. of student are maintained separately. They are not purchasing items and invoiced like customers.

1 Like

Yes but you can link a student to a customer record, the same way Instructor is linked to an Employee record. I think this is the way to implement inheritance in Frappe. A Student is a special type of a Customer.
To me, these features just look too similar

2 Likes

You can then choose to use any of the two features

1 Like

I do not know technical implications at the moment but I believe this is a better strategy to rely on existing doctypes (contacts, items…), linking them rather than creating specific new doctypes. Then, new features on base doctypes can take advantage. Easier maintenance on the long term I think.

with my limited knowledge on technical side of ERPNext, i believe the approach you suggesting should have been adopted first. If its not workable with all possibilities, then additional doc_type makes sense.

The rule of thumb is the context in which a term is used in the real world.

If you would never invoice a student, it should not be a an invoice.

Same reason a Student is not a Party in ERPNext. You would never use those words in the real world.

This is obviously not absolute, but its a great starting point for making such decisions.

3 Likes

I like your approach of using an existing feature rather than to build a new feature as such an approach is simpler, but in a school scenario, especially an Indian school scenario, there is way too much divergence from the standard invoicing process that making such changes on the invoicing process may complicate matters to the organizations that just want to use the standard invoice features. What are these complexities:

  1. Too many fee structures
  2. Too many discounting structures
  3. Too many payment terms (installments as they are called in India)
  4. Revenue recognition complexities
  5. Regulatory reporting complexities

So while I’m completely in line with your approach to take the simple way first, in a typical Indian school environment, we may need to have a different process while we fully understand and tame the complexities. For this reason a different module is perhaps justified.

Once we understand the entire process and we run this at a few schools for a couple of academic years, we may be able to merge it back into the core functionality.

But yes, other things being equal the simpler approach should triumph.

Thanks

Jay

1 Like

One of the things I like about ERPnext is that it is extremely intuitive so that a person who has never used it, but who is familiar with the specific terminology of the domain that he or she operates within can immediately begin using it without a strong need or dependence on documentation.

Sure, one can obviously make the case to operate with the simplified approach and that is enough for many people. In my particular case my employees really like the fact that the program complements their knowledge. They frequently tell me the program makes sense to them in their daily activities.

I can easily recognize that if you take ERP next to a local school and then ask them to start using it they will be able to quickly understand how the software works without the need of too much training.
Teachers, Medical Professionals, Farmers, Hotel managers, etc In a small or medium enterprise will benefit the most out of this!

2 Likes

In my scenario, I am pursuing an opportunity with a university. For them, the finance department is almost detached from the academics. They only meet at the student’s invoice, when the academics department raises an invoice and finance takes over for payment followup. In addition, they have other non-academic revenue streams they invoice. For finance, a student is just another customer.

Especially now we are seeing domain specific ERPNext opportunities (for Education, Healthcare, Agriculture, etc). As more ERPNext for XYZ are going to come up, it will pay off to have an harmonized way of integration

Maybe you should try the invoicing approach with your university. I think most of the things I said can be accomplished on ERPNext with existing features, a quick workaround or some adaptability on the users side.

If that doesn’t work, you always have the reassurance of falling back on the Fee Module

Thanks

Jay

3 Likes

Hi to all… Maybe my case has nothing to do with the term “School” but we have adapted the School module to a CrossFit Gym and we are doing like a school on some parts like … Student Applicant (Subscription) and Program Enrollment with the current Training course they offer.

We setup the Student as Customer once approved and do his Enrollment and create his **Fee Record (**due to pay up to customer)… Together we create his SI tied or with a reference of the Fee record created…

Because this is a service but they still have Instructors/P.Trainers or CrossFit trainers and Students/Customers and they sell Services … invoices are required… So when the Customer/Student decides to pay his Fee the normal process for SI is taken and once submitted the FEE is also set as PAID. Basically we print the SI Incl Taxes if applied instead of the FEE receipt.

Also here in Angola for parents we ask for a Receipt when paying our kids school … because that is a Service being provided by a Company (School, University).