Closed thaliawww-service closed 4 years ago
In GitLab by @thomwiggers on May 9, 2018, 12:32
Wil je niet ook een export maken in het formaat dat je in de automatische-incasso unit kan importeren?
Daarnaast, dit fietst wel een beetje door de plannen voor iDeal #558 ...
In GitLab by @thomwiggers on May 9, 2018, 12:33
Ah, ik zie dat daar een nieuwe ontwikkeling was gepost (iDeal niet wenselijk) die ik nog niet gezien had.
Machtigingen moet je wel technisch gezien een handtekening voor hebben staan...
In GitLab by @thomwiggers on May 9, 2018, 12:35
Volgens mij hanteert Cognac trouwens dit systeem ook, misschien eens met hen praten.
In GitLab by abos on May 9, 2018, 12:39
Conscribo maakt de import voor ING zelf. Ik heb ING gebeld om te vragen of het voldoende was de leden een vinkje te laten zetten, en zij vertelden me dat dat prima was.
In GitLab by @thomwiggers on May 9, 2018, 12:46
Mooi werk. Die export die je voorstelt is te importeren in conscribo?
Wat is je plan voor het bijhouden van het uitstaande debiteurensaldo?
En wat te doen met mislukte betalingen?
In GitLab by @thomwiggers on May 9, 2018, 12:47
En obligatory: gaan we dit doen op de blockchain? :P :chains:
In GitLab by abos on May 9, 2018, 12:49
Die export wordt gebruikt om relaties te importeren. De batch wordt gemaakt adv het relatienummer, welke de maand aangeeft.
Wbt het debiteurensaldo, ik zat te denken bij evenementen het betalingstype 'wallet' te hebben. Dan kan ik deze per evenement optellen en hiervoor een debiteurenboeking aanmaken.
Ik denk dat de mislukte betalingen niet heel vaak voorkomen. Mocht dit wel voorkomen dan mail ik de persoon gewoon even met de vraag of hij of zij wil overmaken.
In GitLab by @thomwiggers on May 9, 2018, 12:50
Ten slotte: maken we dit verplicht voor onze leden?
In GitLab by @thomwiggers on May 9, 2018, 12:51
Oh, en die mail sturen, heb je daar al een automatisch ding voor in conscribo of moeten we dat ook automatiseren.
In GitLab by abos on May 9, 2018, 12:57
Nee, niet verplichten voor leden.
Gaan semi-automatisch via Conscribo, en dat werkt prima.
In GitLab by @thomwiggers on May 9, 2018, 12:58
Mja, 50 per maand is natuurlijk wel een andere orde dan de schaal waarop we nu automatische incasso gebruiken.
In GitLab by abos on May 9, 2018, 12:58
Klopt, maar wat is je punt?
In GitLab by @thomwiggers on May 9, 2018, 13:00
Ik weet niet wat "semi-automatisch" hier precies betekent, maar drie klikken per ding is natuurlijk op zich weinig moeite, maar als je er elke maand 50 moet doen is het wel erg irritant.
In GitLab by @thomwiggers on May 9, 2018, 13:00
Misschien trouwens een goed idee om deze functionaliteit, als het eenmaal gebouwd is, eerst even 'proef te draaien' met alleen onze commissie en bestuur ofzo. Maar dat is voor een later stadium.
In GitLab by abos on May 9, 2018, 13:11
Yeah dat klopt. Ik moet nog even uitzoeken hoeveel moeite het precies is. Heb er n keer mee getest maar is alweer ff geleden.
In GitLab by @se-bastiaan on May 9, 2018, 15:05
Misschien is het een idee om Conscribo om de API documentatie te vragen? Gewoon eens kijken of t helemaal fancy kan.
In GitLab by @thomwiggers on May 9, 2018, 15:06
zou wel chill zijn, dan kun je misschien zelfs de administratie naar hen offloaden.
In GitLab by gmulder on May 9, 2018, 15:08
Ik weet dat Thijs Miedema een hoop tegen Conscribo heeft zitten aanpraten. Automagisch de boekingen in Conscribo zetten lijkt me wel een vereiste, maar dan kan je net zo goed de debiteurenboekhouding voor álle leden inzichtelijk maken (per persoon, uiteraard).
In GitLab by gmulder on May 9, 2018, 15:09
https://github.com/thijsmie/tantalus/blob/master/ConscriboPyAPI/conscribo_api.py
In GitLab by @thomwiggers on May 9, 2018, 15:09
of gewoon Conscribo herimplementeren in de Thaliawebsite, how hard can it be :runner:
In GitLab by @se-bastiaan on May 9, 2018, 15:16
Jammer dat dat Flask is en geen Django :p
Nu heb ik geen idee hoe Conscribo precies werkt, maar het lijkt me niet verstandig om daar alles in te gaan zetten. Je wilt eigenlijk bijhouden wie wat heeft betaald en hóé. Dus cash, pin of incasso. We hebben al een payments package, die vooral gericht is op direct verwerken van betalingen. Voor incasso's moeten we dan bedenken hoe we omgaan met de status van de betaling. Bijv: export is gemaakt maar de betaling is nog niet afgeschreven. Is ie dan betaald? En hoe updaten we die status dan later als we dit zien als 'processing' oid?
In GitLab by gmulder on May 9, 2018, 15:16
Bij KN hebben we dit:
Je kan er ook de balans van de commissies waar je inzit zien (maar misschien gaat dit te ver off-topic).
In GitLab by @se-bastiaan on May 9, 2018, 15:18
Dat is direct vanuit Conscribo gepakt dan?
Ik zou dit overigens graag geen 'wallet' gaan noemen. Liever iets als 'Thalia Pay' :grimacing: . Of serieus gewoon een naam die duidelijker uitlegt wat het eigenlijk is, want een wallet is dit niet echt lijkt me.
In GitLab by gmulder on May 9, 2018, 15:19
Bovenstaand wordt uit GnuCash gehaald.
In GitLab by gmulder on May 9, 2018, 15:22
Bij incasso's is ook nog eens de uitdaging dat binnen 56 dagen de incasso nog teruggeboekt kan worden. De (valuta|rente)datum van de terugboeking is dan hetzelfde als wanneer die in eerste instantie werd afgeschreven.
Je krijgt wel returncodes wat er precies gebeurt is (AM04 voor onvoldoende saldo, AC06 voor 'rekening gesloten', maar zie vooral hier voor een kort overzicht). Voor terugboekingen moet je dat dan weer kunnen matchen met de persoon.
Desondanks kan je er in principe vanuit gaan dat een incasso 'gewoon lukt'. Uitdaging lijkt me dan nog steeds het (periodiek) syncen met Conscribo (want bankinformatie), want anders ben je dubbel werk aan het doen.
In GitLab by @se-bastiaan on Jun 5, 2018, 22:09
Ik heb eens gekeken wat we precies kunnen doen met de API van Conscribo. Het lijkt erop dat alleen relatiebeheer en transacties beschikbaar zijn. Dat betekent dat we wel:
Maar in mijn snelle zoektocht door Conscribo lijkt het er niet op dat je een bepaalde batch aan boekingen kunt pakken om daar vervolgens een incasso van te maken.
Het lijkt me in ieder geval dat wat ik eerder schreef
Voor incasso's moeten we dan bedenken hoe we omgaan met de status van de betaling. Bijv: export is gemaakt maar de betaling is nog niet afgeschreven. Is ie dan betaald? En hoe updaten we die status dan later als we dit zien als 'processing' oid?
het zo intens complex zou maken dat het niet te doen is. En zoals Gerdriaan aangaf kunnen we er ook gewoon vanuit gaan dat een incasso dan lukt. Dan dragen we die taak over aan de boekhouding.
In GitLab by @se-bastiaan on Jan 30, 2019, 22:51
A small update in this issue:
In GitLab by @se-bastiaan on Feb 8, 2019, 22:58
Regarding 'Finding out how we can get permission from members to do direct debits'
Job has written communication from our bank (ING) that it doesn't matter how the mandate is collected (paper or electronic) as long as a judge can be convinced that there is no case of identity fraud. Thus if we collect a signature using a canvas that should work.
For documentation: https://lists.thalia.nu/mailman/private/technicie/2019-February/000034.html
In GitLab by @JobDoesburg on Jun 12, 2019, 13:34
For my own clarity I think it would be nice to have a wrap up of what to do next. Please correct me if I'm wrong:
I think the next thing is to have a payment type 'direct debit' and a way to export all payments of this type per month. The treasurer will then every month
Also the field 'last time used' should be updated every time the treasurer performs these steps. (I think it might be nice to create a new model 'payment batches' similar to something as newsletters, that contains a batch of payments for every month?)
Next would be then that members will have, for events they are registered for (or pizza events), the possibility to hit a 'pay with direct debit' button if they have a valid mandate added to their bank account, which creates such a direct debit payment. Similar should be for registration as member of benefactor and annual contribution for non-study-members (which is already implemented sort of). Also there should be the possibility to have the treasurer add manual direct debit payments (for example for merchandise sales or things that are not on the website).
The only thing then we should maybe think about is how to handle errors from the bank. In case a direct debit fails, it should be paid in a different way. This can be done manually by the treasurer, but those manual corrections should not influence the rest of the system. For example, if a direct debit is cancelled by a member, the debit becomes invalid. This can be changed manually by the treasurer but it shouldn't break things.
In GitLab by @se-bastiaan on Jun 12, 2019, 14:10
I think (1) may be possible in conscribo, (2) and (3) can be automated so far that we add the option to export special CSV files of the payments. We can do this by adding actions to the admin. The treasurer would select all the payments that have to be processed (filter on direct debit & 1 month) then export (which updates 'last used') and from there the rest of the process should be out of our hands.
Manual creation of payments is already possible, if the 'direct debit' type is added that is done.
Handling errors from the bank will just require the treasurer to manually disable the authorisation and there might need to be an option to change the payment type of a payment because 'direct debit' would not be correct anymore if a payment fails.
In GitLab by @thomwiggers on Jun 12, 2019, 14:54
there might need to be an option to change the payment type of a payment because 'direct debit' would not be correct anymore if a payment fails.
It might be more sound to mark that payment as 'failed' and create a new payment, instead of changing it. Especially if the books would still reflect the failed payment.
In GitLab by @se-bastiaan on Jun 12, 2019, 14:55
That would be in the case that the website is the financial administration, which it is not.
In GitLab by @thomwiggers on Jun 12, 2019, 14:58
But then how will the kascommissie check if, e.g., the number of payments in the books matches up with what is in the website... I don't think it's possible to keep the website fully out of 'being the financial administration', if you integrate billing features such as these.
The logs of the 'till' need to be kept somehow.
In GitLab by @se-bastiaan on Jun 12, 2019, 15:01
In that case we could assume that a direct debit always succeeds. Like Gerdriaan proposed: https://gitlab.science.ru.nl/thalia/concrexit/issues/632#note_46691.
Once a payment using direct debit is exported we should be able to hand this off to conscribo.
In GitLab by @thomwiggers on Jun 12, 2019, 15:41
That would probably also be acceptable, yeah. Then you won't allow any kasverschil in the website.
In GitLab by gmulder on Jun 13, 2019, 14:01
@JobDoesburg wrote:
In case a direct debit fails, it should be paid in a different way. This can be done manually by the treasurer, but those manual corrections should not influence the rest of the system. For example, if a direct debit is cancelled by a member, the debit becomes invalid. This can be changed manually by the treasurer but it shouldn't break things.
Or you could keep track of (or calculate on the fly) a running balance after each transaction, e.g.:
type date description amount balance
activity 2019-02-28 Pizza Hawaii -5,00 -5,00
direct-debit 2019-03-31 Balance payment 5,00 0,00
payment 2019-03-31 Failure AM04 -5,00 -5,00 # AM04: insufficient funds
activity 2019-04-01 Pizza Tonno -6,00 -11,00
payment 2019-04-15 Manual payment PH 5,00 -6,00
direct-debit 2019-04-30 Balance payment 6,00 0,00
In this way you can track everything that's payment-related. You don't need a concept of invalidating a direct-debit, because the invalidation is simply a negative payment.
In GitLab by @JobDoesburg on Jun 13, 2019, 16:19
I will try to figure out (1) in Conscribo. So far I haven't seen such a feature yet - Conscribo outsources this to other parties but I haven't looked at it yet in full detail.
In GitLab by @JobDoesburg on Jun 13, 2019, 16:20
I think that is the easiest
In GitLab by @JobDoesburg on Jun 13, 2019, 16:22
I personally think such a thing makes it overcomplicated since those failed payments must be dealt with manually anyhow.
In GitLab by @JobDoesburg on Jun 13, 2019, 16:32
But actually I don't really care
In GitLab by @JobDoesburg on Jun 15, 2019, 15:48
I checked this out on Conscribo. Conscribo does not support a way to send emails with overviews of payments automatically. Conscribo does however support a way to create a batch of payments. If we could sync the 'open balance' amount to Conscribo, I can use Conscribo to create the file to upload to the bank. We must then only in the website create something to with 1 button put all open balances at 0 again. This would however be a different approach then from the less timing-bound approach of batches per month.
I heard that the website will also be containing a page with an overview of all payments of a user. It will then not be necessary to send an email with this overview as well, we could just send an email only saying 'check the website'.
In GitLab by @JobDoesburg on Jun 30, 2019, 15:11
Idea for Thalia Pay (long term) at borrels (or merchandise sale, or other 'unrelated' payments ): admins can create 'empty' payments of a certain amount and type, for example for a/some beer(s). A QR code is then shown on the admin device of an activation-like URL for this payment. A logged in user can open this URL from his own device using the QR code and accepts the payment. Only then the person is added to the payment, which is displayed to the admin.
In GitLab by @se-bastiaan on Jun 30, 2019, 15:32
What problem would this solve exactly? Admins are usually board members, so asking for permission would be kind of double since they are allowed to create payments anyways.
In GitLab by @thomwiggers on Jul 4, 2019, 10:14
This sounds more like adding a cash registry ("kassa") system.
I'm closing this issue because we can now use a project: https://github.com/thaliawww/concrexit/projects/3
In GitLab by abos on May 9, 2018, 12:27
This is the general overview issue for Thalia Pay. The work has been split in multiple subissues that all begin with 'Thalia Pay'
One-sentence description
Members can pay for things by keeping a tab using their account.
Desired behaviour
A member has a virtual wallet with a maximum balance of 0 euro. This wallet can be used to pay for things.
Once a member registers for an event or orders a pizza an option will appear to pay using the wallet. Such a payment is registered in the ~payments app. The amount of the payment will be deducted from the wallet.
At the end of the month all the payments of that month will be collected by direct debit.
Before these direct debits can take place we need to collect information from members:
Then the treasurer has to be able to create an export that contains all the information for a direct debit. The overview only has to contain members that made a payment. It should have the following fields:
The treasurer will send a mail before the direct debit will be executed. But an overview in the frontend of the website would be desirable.
What has been done
What we should do next
Mostly taken from https://gitlab.science.ru.nl/thalia/concrexit/issues/632#note_74956 and responses.