Student Statements Single-Bulk Emailing

[msalim79]

Hello Community
Is there anyone willing to join me or give assistance in building a tool or report to email bulk statements for students in the education module? Like the Process Statement of Accounts for customers.

This is not a paid gig, its a gig to skill-up and contribute back as I have not found an existing solution to send bulk statements for students.

[peterg]

At my organization, we’ve customized the Education domain heavily. I strongly believe that the decision to treat fees as ledger-writing vouchers was a mistake. The Sales Invoice doctype is very sophisticated, and the Fees doctype is very weak by comparison.

I am very happy to help how I can, if there’s a coherent plan that would lead to an upstream PR.

[mujeerhashmi]

Yes, completely agree. The stock items cannot be added to fees like uniform, books etc. The qty option is also not available for fee categories.

I feel it’s necessary to have a customer created for every student so that the sales invoice can be created for service items(fee category) as well as stock items. This is how it works for healthcare domain wherein every patient is linked to customer.

[peterg]

@mujeerhashmi

Yes, completely agree. The stock items cannot be added to fees like uniform, books etc. The qty option is also not available for fee categories.

Indeed, those things and so much more: per-item account heads, payment schedules, reports, taxes and deductions, etc. The Sales Invoice doctype is powerful, sophisticated, and well-tested. I can’t think of any reason to try to recreate that.

@mujeerhashmi

I feel it’s necessary to have a customer created for every student so that the sales invoice can be created for service items(fee category) as well as stock items. This is how it works for healthcare domain wherein every patient is linked to customer.

That’s more or less what we’ve done. We added a “Paying Party” Customer link field in the student doctype, alongside some code to autogenerate a new customer if none exists. Then, we added a few fields to the Fee Structure doctype to provide a bit more accounting information, and we expanded the Program Enrollment doctype to give an option to generate Sales Invoices rather than Fees.

We offered to make a pull request, but the response was that it would make things too complicated. I find using Sales Invoices vastly more flexible, though, and it was a relatively easy customization to make.

[msalim79]

Thanks @peterg and @mujeerhashmi for responding.
So to keep it as simple as possible , we know that every business has its own flavors of doing things, and as such I am pretty sure some education institutes as well.
With Regards to the Education domain I think the fees structure function works well minus the bulk statements for students and unable to add items like uniforms etc but their are ways around that.So if the initial fee includes uniforms,books etc this can be added in the fees structure however it would be the adhoc items during the year that we would want to register a sale against a student using the sales invoicing.

My Suggestion\s are the following :

1. If Education domain is enabled, then on sales invoices creation show party type = Student, now your student become your customer and the process then follows as a normal sale.This should then allow institutes to sell items.No need to recreate them as a customer after we have created them as a student, duplication.
2. Now because party type student is selected when a sale is processed and fees are raised through its education module both voucher type(fees and sales invoice) would hit the ledgers.
3. This now brings us to the issue of Bulk\Single Email Statements , we would need to also include party type if Education Domain is enabled because the data is now in the ledgers it makes it easier to pull that info into a report or the tool.With regards to the single emailing of statements their should\could be an email option on the general ledger , currently has print and pdf, no email.The Auto email function work but needs some tweaking their as well.The single send caters for those students\parents who did not receive their statements in the bulk run or request for a once off statement on their account.

I think i have said a lot, let me know your thoughts and how we can get this off the ground sooner than later.What are the things we can do now and what needs some time to deliver.

[peterg]

@msalim79

I think the fees structure function works well minus the bulk statements for students

For you, the thing missing from Fees is bulk statements. For me, it’s taxes and multiple account headings. For mujeerhashmi, it’s stock tracking. For someone else, it’s payment terms, or it’s dunning, or it’s multi-currency, or it’s deductions, etc. Why recreate (and then maintain) all of this often very complex functionality?

@msalim79

If Education domain is enabled, then on sales invoices creation show party type = Student, now your student become your customer and the process then follows as a normal sale.This should then allow institutes to sell items.No need to recreate them as a customer after we have created them as a student, duplication.

It’s not duplication, though. The Student doctype and the Customer doctype represent very different sets of information, even when they refer to the same human. To make Student work for Sales Invoices, you’d have to add new fields and logic. That’s the real risk of duplication.

@msalim79

Now because party type student is selected when a sale is processed and fees are raised through its education module both voucher type(fees and sales invoice) would hit the ledgers.

This gets messy fast. Allowing Students to be party to both Sales Invoices and Fees would require modifications to many different documents, such as Payment Entry. There’s some new work in the last month or two to allow individuals to be both customers and suppliers, but I haven’t looked at it closely to know if it could carry over here.

[msalim79]

So what do we tackle first ?

[peterg]

The first step, I think, is clarity about goals.

If all you’re trying to do is add something parallel to the Process Statement of Accounts doctype for Fees, it should be pretty straightforward. It wouldn’t take much beyond duplicating what exists and modifying field names a bit. I’m happy to give assistance if you get stuck.

If, on the other hand, we’re trying to generate proper invoices from the Education domain, we’d want to talk to the maintainers to see if something like that would be a desirable contribution.

[msalim79]

If all you’re trying to do is add something parallel to the Process Statement of Accounts doctype for Fees, it should be pretty straightforward. It wouldn’t take much beyond duplicating what exists and modifying field names a bit. I’m happy to give assistance if you get stuck…
Ill take you up on that offer should i get stuck.

If, on the other hand, we’re trying to generate proper invoices from the Education domain, we’d want to talk to the maintainers to see if something like that would be a desirable contribution.
Yes I agree we need to engage with Frappe and see if this is something desirable and in demand. Maybe a PR for this on GIT? We would need to gather all requirements and submit? I can open one take what has been said on this Forum and submit as a start ?

[peterg]

@msalim79

Yes I agree we need to engage with Frappe and see if this is something desirable and in demand. Maybe a PR for this on GIT? We would need to gather all requirements and submit? I can open one take what has been said on this Forum and submit as a start ?

An Issue on GitHub would be the place to start. PRs only get submitted when there’s complete code.