Bij de laatste download van de collectes blijkt bij ons het ‘Total transaction amount’ lager te zijn dan het ‘Total gift amount’. Dit zou toch niet moeten kunnen?
In theorie zou dat niet moeten kunnen inderdaad. Ik vermoed dat er een bug is die transacties wellicht niet goed meetelt als er gebruikers verwijderd zijn. Zijn er gebruikers verwijderd voor zover jij dat weet? Dan kan ik er even induiken.
Nee, ik heb volgens mij geen gebruikers verwijderd de afgelopen 6 maanden. Ik zag dat het totaalsaldo sinds ongeveer 20 juni negatief is geworden, maar ik heb verder geen informatie waardoor en per wanneer dit zou kunnen zijn veroorzaakt.
Deze is erg vervelend (vooral voor de kerken die giften krijgen van app-gebruikers zonder dat ze een account gebruiken).
Het was een zoektocht, maar het lijkt erop dat in sommige gevallen giften dubbel in de database terecht komen. Stel iemand geeft €1 in de collecte, worden er soms twee giften van €1 en dus totaal €2 geregistreerd.
Dit gebeurt alleen als er gegeven wordt zonder een account. En ook in dat geval treedt de bug vaker niet op dan wel. Maar alsnog heel vervelend (ook dat ie niet eerder aan het licht is gekomen), mijn excuses hiervoor.
Dit heeft te maken met de afhandeling van de iDeal-betaling met de daaraan gekoppelde giften in de collecte. Wat ik vermoed dat er gebeurt is dat de url waar je naar door wordt verwezen twee keer op exact hetzelfde moment aangeroepen wordt in sommige gevallen.
De flow als je zonder account wilt geven nadat de iDeal-betaling is afgerond:
- betaling wordt opgezocht in de database
- er wordt gekeken of de betaling al is geregistreerd als afgerond en verwerkt;
- als deze niet zo geregistreerd staat, wordt deze opgehaald bij Mollie;
- als deze afgerond is, wordt de betaling in de database op geregistreerd gezet;
- vervolgens worden de gekoppelde giften verwerkt;
- het saldo (dat inmiddels €0 is) wordt in de database opgeslagen
Als de url twee keer tegelijkertijd wordt aangeroepen gaat het mis bij de dikgedrukte stap. De betaling is in beide gevallen nog niet verwerkt (het kost even tijd om de status op te halen bij Mollie enz.) Vervolgens worden de verdere stappen doorlopen met als gevolg dat er één betaling is met twee giften.
De oplossing is om direct in stap 1 de betaling te markeren als “in behandeling” en na het ophalen van de status bij Mollie nogmaals de betaling in de database op te halen of deze inmiddels niet al wel afgerond is, op die manier wordt de kans op overlap nihil.
Kerken waarvoor het relevant is, ontvangen binnenkort een mail met alle details.
1 like
Naar de kerken wie het betreft heb ik deze mail gestuurd:
Goedemorgen Peter Arends,
Helaas is er in totaal € 2 teveel aan giften geregistreerd in jullie chrch-omgeving. Zie voor meer informatie Negatief saldo tegoed.
In de chrch-app Admin vind je in de Excel-export van de collectes een extra tabblad “Corrections”. Daar staat gespecificeerd welke giften per ongeluk dubbel zijn geregistreerd. Ook vind je de totalen per collectedoel.
De dubbele giften staan nu nog wel onder “All proceeds” en worden nog meegeteld in de “Summary” en “Proceeds per week”.
Heel vervelend natuurlijk, mijn excuses voor het ongemak.
Vriendelijke groet,
Peter Arends
ps: deze mail is geautomatiseerd opgesteld aan de contactpersoon die jullie hebben ingesteld in jullie chrch-omgeving
2 likes
Ha Peter,
Even een check. Is de bug inmiddels gerepareerd?
Want ik zie in de Brugkerk Waddinxveen nog een dubbele bijdrage om 2023-08-13 17:26:16.
Ik hoor het graag, mag ook per mail.
Ja de bug was gelijk verholpen in principe, ik duik er weer even in.
Het is de enige die na de fix niet goed is gegaan, bedankt voor het melden. Ik heb nog even twee dingen aangepast die het zouden moeten fixen. Ik hou het in de gaten.
2 likes
Peter, ik had ook al via de mail geantwoord, maar weet niet of die mail is aangekomen: zou het niet goed zijn als er regelmatig een aansluiting gemaakt zou kunnen worden tussen het saldo dat wordt getoond als de collecten worden gedownload en het totaal van de tegoeden van de deelnemers bij de desbetreffende kerk? Bijvoorbeeld door een totaalbedrag van allle tegoeden van alle deelnemers van de kerk ook te tonen in de download? Op die manier kan de beheerder snel zelf signaleren dat er om wat voor reden dan ook een verschil is ontstaan.
Ja, goed idee @tgkok. Als ik drie bedragen opneem: totaal betaald via iDeal, totaal openstaand tegoed en totaal besteed aan collectes, kun je altijd nagaan of het klopt. Is dat ook wat jij bedoelt?
Ja dat is precies wat ik bedoel.
Peter, staat dit idee nog steeds op de wensenlijst? Ik zou graag duidelijkheid willen hebben of het getoonde openstaande saldo echt klopt. Ik heb m.n. bij sommige posten uit het verleden (van voor de melding van deze bug) nog steeds wat twijfels. Is het wellicht in ieder geval mogelijk om het volgende bevestigd te krijgen:
- transacties 1667249041, 1669754191 en 1680344974 staan bij ons in de Corrections tab; zijn dit echt dubbel verwerkte transacties? Deze zie ik namelijk niet direct als dubbele transacties in de ‘All proceeds’ tab - al staan daar wel identieke transacties met de nummers 1667249040, 1669754190 en 1680344973.
- de transacties 1633473852 en 1630254206 zijn niet vermeld als dubbele transacties, maar deze vertonen wel kenmerken van dubbel verwerkte transacties.
Dank alvast!
Dank voor je geduld @tgkok en staat nog steeds op de wensenlijst.
De verwarring komt denk ik doordat je de timestamp aanziet als een id. Die nummers die je noemt zijn een andere weergave van de datum. Dus 1667249041, 1669754191 en 1680344974 zijn hetzelfde als 1667249040, 1669754190 en 1680344973 alleen met een seconde verschil. Vandaar aangemerkt als dubbel.
Het zou kunnen dat de gaven (dus niet transacties/iDeal betalingen) die dubbel lijken en de timestamps van 1633473852 en 1630254206 hebben inderdaad dubbel zijn. Dit is lastiger te achterhalen omdat ze blijkbaar uit een tegoed komen en niet gekoppeld zijn aan een directe iDeal-betaling. Dat dit mis is gegaan heeft een andere oorzaak voor zover ik het kan inschatten. De andere hadden te maken met een iDeal-betaling die twee keer bevestigd werd en deze denk ik met een connectie naar de database die bijvoorbeeld niet goed ging.
Ik kom hier nog op terug.