Reports

[mhvis]

Finance reports:

• Balance report: shows the start and end balance for associations and kitchen cost.
• Cash flow matrix: shows the flow of money between accounts.
• Site transactions: lists all transactions on the site, except for user transactions (deposits/withdrawals/kitchen payments).
• Stale accounts report: determines the age of an account by their last transaction date, and aggregates them in groups depending on their age.

Dining reports:

• Diners: cooked for/kitchen usage/...
• Membership counts
• Leaderboard

Screenshots:

[DutcherNL]

The idea of Django is that you don't have to focus on SQL queries. Is the reason you placed the commented SQL queries purely as a replacement for test-cases? If so, honestly, I think it's not neccessary honestly as long as the function is well documented in what it intends to do.

[mhvis]

I used the generated SQL queries to come up with the correct QuerySet code and check that it's correct. It's much easier to see what is happening in the SQL and whether I would need to use DISTINCT somewhere. I left the queries there just for documentation.

The idea for Django's ORM is not to not use SQL, but as an abstraction so that you can use multiple databases with their own SQL dialects, and as a mapper between rows and Python objects ('Object Relational Mapping'). There is nothing wrong with SQL, in fact I would prefer it if the object mapping wasn't such a great feature of Django.