Baseball bat is a web platform with the aim of reducing our organization's treasurer's workload by automating different parts of the event fee billing process. In the future the platform will hopefully enable online payments via Stripe and make collaboration between the treasurer, assisting treasurer and the event organizers easier.
- Importing events and registrations from our event calendar and creating invoices from those based on customizable set of rules.
- Sending emails to members about new invoices
- Sending payment notices to members about overdue invoices automatically
- Keeping track of which payments have been paid by associating bank transactions either automatically using the reference number or manually
- Import bank transactions using an electronic bank statement in the CAMT.052 XML format
- Allow members to view their paid and unpaid debts
- Allow members to pay all their debts using a single payment
- Allow members to pay online using Stripe
This service depends on the following other TKO-äly services, so go and setup those first:
- Members service
- Events microservice
- Users microservice
To set up the development environment do the following:
- Copy the
.env.examplefile to.envand populate the environment variables according to the comments in the file. - Run
docker-compose up -dto start up the containers - Run
npx node-pg-migrate -d POSTGRES_CONNECTION_STRING upto run the database migrations - Run
yarn start:devto start the development server
Better way to setup the service is by using the tko-aly.localhost repository which includes all the required services, completely containerized, and a Traefik installation which routes all the services to domains under .tko-aly.localhost.
The data model is designed to be able to handle the following scenario:
- User signs up as TKO-äly member using the email address
janne.jasen@gmail.com - User registers to a TKO-äly event outside of our event calendar (for example Google Forms or similar, which are sometimes used), and uses the (different) email address
janne.jasen@helsinki.fi - User registers to an another TKO-äly event using the event calendar
- User receives an invoice sent to
janne.jasen@helsinki.fibut it goes unnoticed - User receives an invoice sent to
janne.jasen@gmail.comand clicks the link in the invoice message - User wants to pay both of their debts using a single transfer and generates a new reference number for that purpose
- User makes a transaction using the correct reference number but enters the amount incorrectly
- User receives a notification about the mistake from the system and either pays the difference, in case of underpayment, or the receives the overpaid amount from the treasurer
There are four main things that make this scenario difficult to handle correctly:
- There are two profiles for the user in the system: one with the email
janne.jasen@gmail.comand an associated membership ID, and one with the emailjanne.jasen@helsinki.fiand no associated membership ID. The system must be able to merge these two profiles, when the fact that these are the same user transpires. - The system must be able to handle under- and overpayment and multiple transactions and payment events towards a single payment.
- A single payment must be able to cover multiple debts.
- When user pays the combined invoice, which covers the two debts, there still remains the invoices originally generated for these debts and that were sent using email to the user. These old invoices must be automatically credited or invalidated.
