Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion]: What is needed for from the frontend for a good financial audit? #506

Open
JustSamuel opened this issue Feb 19, 2025 · 2 comments

Comments

@JustSamuel
Copy link
Contributor

During my 26 hours of fixing the bookkeeping, I had to use a lot of db queries, which was fine since I can access the db, but for years after me this information should be provided by the dashboard. Therefore, I am suggesting creating a "financial insights" tab / module that helps doing such an audit without db queries.

The main goal in this tab is to be able to quickly check numbers from our bookkeeping with those in SudoSOS. The scope is therefore mostly to present numbers for a bookyear / quartile.

The main numbers are

  • The top-ups
  • The total writeoffs
  • The total payouts
  • The total seller payouts
  • The total amount of invoices
  • The total amount of fines

These numbers together describe how the balance in SudoSOS changed.

To be able to also nicely check these numbers, we should be able to export these list to an csv, but that will be a backend issue.

@Jobbiesaus
Copy link
Contributor

I completely agree with Samuel on this. He had to take time out of his "afstuderen" to help me get the correct numbers, I do not think the ABC should be involved in finances.

Furthermore, all of these should be possible to accessed with exact dates.

@tomudding
Copy link
Member

As mentioned in the boardroom, I think this is an excellent idea and a wise thing to implement.

  • The total amount of fines

Make sure that the amount of waived fines is also very clear to avoid any confusion in that regard.

I do not know whether it should be part of this overview or something else, but today, we noticed an issue in the fine -> transfer mapping because of a lack of foreign key constraints. That is also something you ideally want to be able to see (however, if we can ensure/be sure that this never happens again, we do not need such functionality).

Another thing: How would we represent refunds? We have not had to deal with that yet, but it is something to consider.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants