Groceries/shopping cost handling

[mhvis]

I was thinking of using this issue to look into some options for handling groceries costs, if you're all fine with that. I can think of the following general approaches for this:

• System like WieBetaaltWat where the grocery payments are stored in the database and people can see the debt that they have between each other due to these payments. Debts from both sides cancel out and people can at any moment choose to resolve debts. We can create some system for making resolving debts as easy as possible.
• Same system like for kitchen costs, where the groceries costs get subtracted from your balance. This means that your balance could become more and more positive and then you would be able to retrieve this money from Scala, since it's physically stored in the Scala money-box. Money is of course also physically stored at intermediary associations, but from there it should always end up at Scala in the end (side note: I was wondering if there's a system in place for this 😀?). It could also be payed out to users directly via association treasurers which would require more administration, more responsibility for the system for correctly keeping track of that. The user balance can of course become negative more quickly as well with this approach which would simply mean more payments to a treasurer.
• Let the user create a payment link and share it. It is already like this somewhat but we then should improve the share mechanism using notifications, and maybe do some more automation.
  In this approach, the user would need to keep track of the payments herself. It's not possible to hook into the payment mechanism and have this done automatically, so the user would need to keep track of this manually. This process can be helped somewhat by the 'Paid' button that we already have in the entries list, however that is still a manual process which requires a lot of user effort and is error-prone.

Do you guys have other ideas? We can review some advantages and disadvantages of these or other approaches and try to go towards choosing one, without looking at implementation details yet.

My preference is currently towards the first option, by looking at effort needed by users and association boards. Second option would mean that there needs to be a procedure in place for withdrawing money requiring association efforts and people would need to deposit more often, also there's a higher responsibility for the system/Scala. Third option has the same user effort as we have now of creation of payment requests and keeping track of who was paid. First option also needs payment requests or direct cash transfers between people like option 3 but reduces the number of transfers and makes it more voluntary (vrij) as to when and how it is settled.

Aside: betaalverzoekjes automatiseren

Ik heb best uitgebreid rondgekeken naar opties voor 't automatiseren van die betaalverzoekjes of alternatieve methodes maar eigenlijk alle manieren van iDeal betalingen via een API kosten geld, normaliter 25 cent per transactie, ook voor betaalverzoekjes en betalingen onderling. Het automatisch aanmaken van gratis Tikkies en dergelijke is niet toegestaan al zou dat best mogelijk zijn. Ik zie ook wel 't probleem dat dan het systeem verantwoordelijk is voor het juist invullen van de IBAN van de ontvanger en niet meer de gebruiker, en de betaler zou niet eens kunnen checken of de ontvanger wel klopt. Dus het lijkt me slim om het daadwerkelijk overmaken zoveel mogelijk onderling te houden en niet teveel via 't systeem.

Er is wel iets wat aardig in de buurt komt van automatische betaalverzoekjes, bunq heeft namelijk een zelfde soort systeem als Tikkie maar in plaats van dat dat via een app werkt, hebben zij het via een site die ook nog eens heel simpel te gebruiken zou zijn bij onze site. Dat is https://bunq.me en gebruikers moeten daar eerst registreren door invullen van IBAN analoog aan 't installeren van de Tikkie app. Daarna heb je een link die oneindig gebruikt kan worden voor 't ontvangen van betalingen. Het bedrag van die betaling is o.a. in te stellen via de link, bijv dit: https://bunq.me/mhvis/4.99. Dit systeem is uiteraard makkelijk te verwerken in de site door mensen hun bunq adres te laten aangeven in hun profiel en dan kunnen er zo automatische linkjes gemaakt worden door het bedrag erachter te plakken en via push notificaties kunnen die links dan naar anderen gestuurd worden.

[mhvis]

I've discussed about it and the scale is likely too big for a system like WieBetaaltWat. Someone suggested that the transaction fees for iDeal and the like may not be too big an issue for users, as well as that Scala would be storing your balance. In that case, we could consider supporting iDeal, linked to the Scala bank account, and have shopping costs subtracted from your balance just like the kitchen costs. iDeal support would be helpful in this case since there would be more need to deposit money more often.

Cash deposits should still be possible next to the iDeal obviously, thought they could always go directly to Scala instead of via another association, since there would be an alternative which makes it less essential to always have the possibility for cash deposits. However associations can also keep on being the middle man and pass on the money via them to Scala.

By making depositing easier there's less reason to have a negative balance, so we could increase the minimum required balance to e.g. -1. For Quadrivium members we can 'safely' have the exception of allowing unlimited negative balance (#116), due to that the system at Q ensures that all money will be retrieved at the end of the year.

When someone cooks a lot she can get a high positive balance so there would need to be some procedure for withdrawing money, but that's probably not a big issue.