How to track payments efficiently?

[al3001]

Hi, currently I am considering to use strichliste2.0 in our club and am testing out your software. But I have not found a good way to track payments, as for my use case, they would be irregular (1-2 times per year per user) and should only be allowed to be processed by authorized persons (that would get access to the backend).

1. So what would be the best practice for tracking payments of users? (In which way is the current software intended to be used for this purpose, solely based on the reports?)
2. Does the balance per user is only shown for the current and the last month? Does this also apply to the exported reports? And older open amounts are not shown anymore?
3. Is there a possibility to set all, or a part, of all open balances for a user to paid? Maybe just from within the backend? I did not found an option and it seems quit messy for my use case to assign and track payments based on the csv output solely. Maybe I overlooked a feature (if not, it may be a feature request).

Nevertheless thank you for this nice software.

[maxmunzel]

Hi!

Happy to hear you consider strichliste2.0 for your club!

strichliste2.0 is focussed on replacing tally lists – no more, no less. ("strichliste" is german for "tally list")

Our club uses a separate accounting software and imports the monthly reports from strichliste – this saves a lot
of manual work.

Back when I did the accounting, we used a software called "Quicken", meanwhile renamed to "FinanzManager",
but most accounting software should support importing expenses from CSV files.

Accounting is quite involved and good accouting software helps you with bank withdrawals, budgeting, invoicing,
membership costs, integrates with your bank etc pp.

If you want to shoehorn strichliste into a general purpose accounting solution, you could add a "Location" for the
accountant that has products like "+1€", "+10€", "+100€" that have negative prices and adjust the reports to include the total
of all transactions -- not just the last month. This way you can top up people's balance after they payed.

The work required for this is quite minimal:
Add a corresponding line to cronjobs/monthly/report for the overview of total balances (not just last month's) and modify the backend to allow negative prices for products. The only thing stopping you at the moment is that Elm's Parser.float doesn't handle negative numbers (

strichliste2.0/src/Backend.elm

Line 212 in 7a0eaba

Parser.run Parser.float <| String.replace "," "." <| stripZero <| model.new_product_price

).
You can fix this or simply add the negative price directly in the database -- you only need to add those magic products once.

All in all, a little SQL should be all you need to hack strichliste into your use-case. Let me know how it goes or if you need any other help. Otherwise, you can always use some proper accounting program (with all the bells and whistles) and just use strichliste as a tally list to track peoples expenses.

[maxmunzel]

By the way: How did you find strichliste? :)

[al3001]

Thanks for your fast reply. For our general accounting (membership fee, etc.) we have a solution that should be kept independent from the bar counter and is only operated by the cashier (including SEPA-Lastschriften, etc.). Our current tally list for the bar counter is operated by a few more people ("barkeepers") and payments for that are only settled in cash. That way, the bar counter is self maintained and the open amounts are paid irregularly by the members. While every member has to pay membership fees etc., not everyone is drinking at the bar, and from the ones that do, some do more and some do less and also have to pay more often or less...

An extra device with 'negative drinks' sounds like a doable solution. But for some of our barkeepers, a csv file may be too complicated to handle. So if the csv exports could be modified easily, would it also be possible to modify the per user "Kosten in diesem Monat" or "Kosten im vergangenen Monat" to show "total costs"? That way also the updated amount would be shown, so that the open amount reduces when something was paid (i.e. a product with negative amount was purchased). Like a live update, which would be missing when using the monthly csv exports.

Nevertheless I already struggled to get a closer look into the database. Executing

psql -d postgres://db:5432 -U postgres --csv -c "select * from information_schema.tables;" > /reports/22.csv

in the cron docker container showed something like this (just the first six lines):

table_catalog	table_schema	table_name		table_type	self_referencing_column_name	reference_generation	user_defined_type_catalog	user_defined_type_schema	user_defined_type_name	is_insertable_into	is_typed	commit_action
postgres	strichliste	history			VIEW						NO	NO	
postgres	strichliste	cost_last_30_days	VIEW						NO	NO	
postgres	strichliste	alc_ml_last_30_days	VIEW						NO	NO	
postgres	strichliste	cost_this_month		VIEW						NO	NO	
postgres	strichliste	cost_last_month		VIEW						NO	NO	
postgres	strichliste	users_and_costs		VIEW						NO	NO	

But when exporting the users_and_costs table, it shows again only the costs from the last two months:

id	name	avatar						active	cost_last_30_days	cost_this_month	cost_last_month	alc_ml_last_30_days
1	test	/profile_pics/PAKNXVRUCP6TZPLNXM7EN4CAD.png	t	4.5			4.5		0		75

So where should I look into, to get the total costs of even older purchases?

I can not remember how I found your software. Likely I searched for Strichliste, as there is another software called like this which I saw in action at another club (https://www.strichliste.org/). But your software is a lot easier to install and looks much nicer with all the pictures :D

[maxmunzel]

The table you’re looking for “history”. It’s a list of all not-undone transactions joined with the users. Speaking of which: The undo feature can effectively be used to mark transactions as paid. The UI implementing it is in the “backend”.

You may want to have a look into the Schema for details:

strichliste2.0/postgres_schema.sql

Line 38 in 7a0eaba

create or replace view history as